Skip to main content
With Containers, you connect a registry, add images, and scan each image for vulnerable packages, malicious packages, secrets, misconfigurations, and outdated base images. Strix identifies an image by its digest, so a scan always applies to one immutable image. Containers is part of the Enterprise plan. Every request in this guide returns 403 with the code enterprise_plan_required on other plans.

How a scan works

  1. Strix resolves the image reference to a manifest digest and a platform.
  2. Strix pulls the image layers with the registry credential on the trusted orchestrator. The credential never enters the scan sandbox.
  3. The scan sandbox receives the image as a read-only OCI layout and runs the package, secret, and configuration checks.
  4. Strix stores each finding in the same vulnerability list that the rest of the workspace uses. Findings that appear in a new scan of the same image keep their history. Findings that no longer appear are marked as fixed.
Strix stores only a masked value or a SHA-256 fingerprint for a secret finding. Strix does not store the secret value.

Connect a registry

Every image belongs to a registry connection. Create the connection first. For a public registry, leave the credential fields empty.
Every registry uses the same OCI Distribution API. The provider field selects the host rules and the credential shape:

Amazon ECR

Strix stores no AWS credential for an Amazon ECR registry. Strix assumes the IAM role in aws_role_arn with the external ID of your workspace, then calls ecr:GetAuthorizationToken to get a registry password. Strix repeats this on every verification, tag resolution, and pull. The password lives for 12 hours and Strix does not store it. In the dashboard, Set up the role opens a CloudFormation quick-create link that creates the role with the trust policy and the read-only actions filled in. Then paste the role ARN into the dialog. To create the role by hand, call GET /containers/registries/ecr-setup to get the values that the role needs:
  • external_id: the value that the trust policy of the role must require in the sts:ExternalId condition.
  • strix_account_id: the only AWS account that the role must trust.
  • role_name: the role name that the CloudFormation template creates.
  • quick_create_url: a CloudFormation quick-create link that creates the role, or null if this server does not host the template.
  • actions: the ECR actions that the role needs if you create the role by hand.
Trust policy:
Permissions policy:
The role must be in the AWS account and the AWS partition that own the registry. AWS credentials do not work across partitions, so Strix Cloud connects registries in the commercial aws partition only. A self-hosted deployment can connect registries in AWS China (amazonaws.com.cn, roles arn:aws-cn:iam::…) or AWS GovCloud (roles arn:aws-us-gov:iam::…) when its Strix principal is in that partition and STRIX_AWS_PARTITION names it. The quick-create link opens the commercial AWS console, so create the role by hand in those partitions. If the trust policy does not allow the Strix account with the external ID, the connection fails with the status disconnected and an error that names the role.

Google Artifact Registry

Create a service account with the Artifact Registry Reader role, then create a JSON key for it. Send the full key file in secret. Strix checks that the file is a service_account key with a client_email and a private_key before Strix stores it. Strix identifies the connection by the registry host and the client_email of the key. You can connect more than one service account to the same regional host. Strix rejects a second connection with the same host and the same service account. Strix encrypts the secret value and never returns it. Strix verifies the connection when you create it. Call POST /containers/registries/{registryId}/verify to check the connection again. Required scope: containers:write Workspace admins and analysts can create, verify, or delete a registry. Members with an asset-scoped role cannot change registries or images, because registries and images have no target, tag, or business-unit labels.

Add an image

The reference field accepts name:tag or name@sha256:<digest>, without the registry host. The registry_id field is required and must name a connected registry. Set platform to null to use linux/amd64. Strix stores the platform on the image. A later scan uses the stored platform if the scan request does not specify a platform. Set scan to true to start the first scan when the image is added. The default is false. The response contains the stored image, the resolved digest, and the first scan when scan is true. If the first scan cannot start, the response contains a scan_error message and the image stays in the inventory. Required scope: containers:write Workspace admins and analysts can add, update, scan, and delete images.

Watch tags

Set watch_tags to a tag pattern when you add an image, or change it later with PATCH /containers/images/{imageId}. Set watch_tags to null to stop watching tags.

Start a scan

If the request has no tag, the scan resolves the tag from the latest scan. If the image has no tag, the scan resolves the digest from the add request. If the request has no platform, the scan uses the platform stored on the image. Each image has one queued or running scan at a time. A second request returns 409 while that scan runs. List the scan history with GET /containers/images/{imageId}/scans. A scan can have a cost limit (on self-hosted deployments, CONTAINER_SCAN_MAX_BUDGET_USD). If a scan reaches the limit before the analysis is complete, the scan completes with stop_reason set to budget_exceeded. If the model provider limits the run, stop_reason is rate_limited. Strix keeps the findings that the scan filed before the stop. Strix does not mark findings as fixed after a stopped scan. The scan history shows the scan as Stopped early. Required scope: containers:write

Read findings

Filter with these query parameters:
  • type: known_vulnerability, malicious_package, secret, misconfiguration, or base_image_outdated
  • severity: one severity level
  • state: open, fixed, or ignored
Each finding contains the layer digest and the file path when Strix knows them. A package finding also contains the package name, the installed version, and the fixed version when one exists. A secret finding also contains a verification verdict, the verified_by explanation, and verified_at:
  • active: the credential’s own provider accepted it. Rotate it now.
  • inactive: the provider rejected it. The credential is revoked or rotated.
  • valid_unverified: an offline proof succeeded, for example a private key that signs and verifies, but there is no provider to ask.
  • unverified: Strix could not prove or disprove that the credential is real. verified_by says what Strix checked.
Strix checks a credential only against its own provider and only with read-only calls. A network or provider failure never produces inactive. Strix does not file example, fixture, or placeholder values. Required scope: containers:read

Read the software bill of materials

The response lists the packages of the latest completed scan with the package URL, the ecosystem, the license, and the layer that added the package. Set scan_id to read the components of an earlier scan. To download the same inventory as a standard document, request the export route with format=spdx or format=cyclonedx:
The route returns an SPDX 2.3 or a CycloneDX 1.6 JSON file for the latest completed scan. Set scan_id to export an earlier scan. The dashboard uses the same route for the Export SBOM… menu on the SBOM tab. GET /containers/images/{imageId} returns the image with its scans, layers, image configuration, findings, and components in one response. GET /containers/summary returns the workspace counts of images, critical findings, reachable findings, and secrets. Required scope: containers:read

Delete an image or a registry

When you delete an image, Strix closes its open findings. When you delete a registry, Strix deletes every image of that registry and closes their findings. If a scan of an affected image is queued or running, both requests return 409. Wait until the scan finishes, or cancel the scan, and then send the delete request again. Required scope: containers:write