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

In Add registry, a green Saved check means the entered value is kept between steps while setup is open. Select Connect registry to store the connection. Closing setup clears the draft. Every image belongs to a registry connection. Open Containers → Registries → Add registry and select the provider. For public Docker Hub images or public generic registries, leave both credential fields empty.
Every registry uses the same OCI Distribution API. The provider field selects the host rules and the credential shape:

Docker Hub

For public images, leave Docker Hub username and Access token empty.
  1. Open Docker Home. Select your avatar → Account settings → Personal access tokens.
  2. Select Generate new token. Enter Strix image reader in Description. Choose an Expiration date.
  3. Set Access permissions to Read. Select Generate.
  4. In Strix, enter the Docker Hub username for the account that created the token.
  5. Copy the generated token into Access token.

GitHub Container Registry

Use your personal GitHub username and a token that can read the packages. Select the package owner separately from these credentials.
  1. Open GitHub token settings.
  2. Select Generate new token → Generate new token (classic).
  3. Enter Strix image reader in Note. Choose an Expiration.
  4. Select the read:packages scope. Select Generate token.
  5. In Strix, select GitHub. Enter your personal account name in GitHub username, not the organization name.
  6. Copy the generated token into Personal access token.
  7. Select Next. Under Package owner, select Personal account or Organization.
  8. For Organization, enter Organization name. Select Connect registry.
If the package organization requires SSO, authorize the token for that organization. The registry host is ghcr.io. Strix sets this host automatically. Strix saves the selected owner and lists that account’s images automatically. You can connect your personal account and multiple organizations with the same credentials. Older connections keep their existing behavior. Connect the organization separately to use account-specific discovery.

Generic registries

Use this provider for registries such as Harbor, Nexus, Artifactory, Quay, or GitLab.
  1. In Strix, select Generic.
  2. Enter Registry host, for example registry.example.com. Omit https:// and the image path.
  3. Enter Username and Token or password for an account that can read the images.
For public images, leave both credential fields empty.

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. The dashboard provides a role template download. Strix fills in the trust policy, workspace values, and image-read permissions. The download works even when a hosted quick-create template is unavailable.
  1. Open Amazon ECR in the account and region that contain your images. Open a private repository.
  2. Copy the hostname from the repository URI, for example 123456789012.dkr.ecr.us-east-1.amazonaws.com. Omit https:// and the repository name.
  3. Select Download role template. This CloudFormation template creates an IAM role that lets Strix list and pull ECR images, without write access. Save strix-container-pull.json.
  4. Keep the AWS account you used for the ECR repository. Select the repository’s region from the top toolbar’s Region selector.
  5. Open CloudFormation → Stacks → Create stack → With new resources (standard).
  6. Select Choose an existing template → Upload a template file. Upload the downloaded file. Click Next.
  7. Enter StrixContainerPull as the Stack name. Keep the supplied StrixPrincipalAccountId, ExternalId, and RoleName values.
  8. Click Next. Leave the optional IAM role under Permissions empty.
  9. Click Next. Review the stack. Acknowledge IAM resource creation. Click Submit.
  10. Wait for CREATE_COMPLETE. Open the stack’s Outputs tab. Copy RoleArn into Strix’s IAM role ARN field.
If you cannot create IAM roles, ask your AWS administrator. If Open CloudFormation is available, you can also use that quick-create link to create the image-read role. 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. For those partitions, upload the downloaded template in the matching AWS console instead. 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.

Azure Container Registry

Strix uses a dedicated Azure app identity to read images. This connection does not use Microsoft sign-in.
  1. Open Azure Portal → Container Registries → your registry → Overview. Copy Login server, for example myregistry.azurecr.io.
  2. Open Microsoft Entra ID → App registrations → New registration.
  3. Name the app Strix container scanning. Select accounts in your organization only. Leave the redirect URI empty. Select Register.
  4. Copy the Client ID from the app’s Overview page.
  5. Open Certificates & secrets → New client secret. Choose an expiration. Create the secret.
  6. Copy the secret Value into Client Secret in Strix. Azure only shows the Value once.
  7. Return to Azure Portal → Container Registries → your registry → Access control (IAM) → Add role assignment.
  8. On the Role tab, select AcrPull. Click Next.
  9. On the Members tab, keep User, group, or service principal selected. Click + Select members.
  10. Search for your app registration’s name, for example Strix container scanning. Select the app.
  11. Click Select at the bottom of the member picker. Check that the app now appears under Members.
  12. Click Review + assign. Check the role and app. Click Review + assign again to save the assignment.
Scope access to this registry. For registries that use RBAC + ABAC, assign these roles instead:
  • Container Registry Repository Reader
  • Container Registry Repository Catalog Lister
For each role, follow the same member selection and confirmation steps above. If you cannot assign roles, ask your Azure administrator. Replace the credential before the secret expires. Microsoft setup documentation

Google Artifact Registry

Create a service account. Grant Artifact Registry Viewer or Artifact Registry Reader on the repository. Then create a JSON key. 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.
  1. Open Google Cloud Console. Select the project that contains your images. Open Artifact Registry → Repositories.
  2. Find your Docker repository in the repository list. Read its Location column. Use the location code, not the display name.
  3. In Strix, enter the location code followed by -docker.pkg.dev. For example, us-central1 (Iowa) becomes us-central1-docker.pkg.dev. Do not include https://, the project ID, or the repository name.
  4. In the same project, open IAM & Admin → Service Accounts → Create service account.
  5. In Service account details, enter Strix image reader as the service account name. Keep the generated Service account ID. Leave the optional description empty. Select Create and continue.
  6. In Permissions (optional), leave Select a role empty. Do not grant project permissions here. Select Continue. You will grant image-read access on the specific repository in a later step.
  7. In Principals with access (optional), leave Service account users role and Service account admins role empty. You do not need to add any principals. Select Done. Strix uses the downloaded JSON key, so this connection does not need users or groups assigned to the service account.
  8. Copy the new service account email from the Service Accounts list.
  9. Return to Artifact Registry → Repositories. Select the checkbox beside your repository. If necessary, select Show info panel.
  10. In the panel, open Permissions → Add principal (or Grant access). Enter the service account email in New principals.
  11. In Select a role, select Artifact Registry Viewer or Artifact Registry Reader. Both roles let Strix read images. Leave the optional IAM condition unset. Select Save. Repeat for each repository Strix will read. This grants access to those repositories, not the entire project.
  12. Open the service account → Keys → Add key → Create new key. Select JSON. Select Create.
  13. Open the downloaded file. Paste the entire JSON content into Service account key in Strix.
Do not grant Editor or Owner. If you cannot assign roles, ask your Google Cloud administrator. Keep the JSON key private. If your organization blocks key creation, ask your administrator about an approved connection method. This key grants image access only. Connect Pub/Sub push events separately. Google authentication documentation 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

In Containers → Images → Add image, select a registry connection. Each option shows the provider name, logo, and registry host. Select Browse registry images… to load image names. Docker Hub lets you change the user or organization namespace. For GitHub, Strix lists images from the package owner selected during connection. Connect a different GitHub account separately to browse its images. The namespace defaults to the connection username. Anonymous Docker Hub connections default to library. For Google Artifact Registry, enter Project ID / repository, such as my-project/my-repository. Strix lists images through repository-level read access. You do not need permission to list all repositories in the project. For nested images, append the folder path to the project and repository. Search the current page or use Next and Previous to browse other pages. Select an image to fill Image repository with its repository path. Strix does not add a tag to the path. After you add the image, select Scan new pushes to include it in Auto Scan. This step shows the registry’s shared tag rule. Change the rule in Registries → Auto Scan. The registry must have a push-event connection and Auto Scan turned on. Strix reads available versions after you choose or enter an image path. Strix shows the detected tag and digest and fills Initial scan version. For Google Artifact Registry, use the full path PROJECT-ID/REPOSITORY/IMAGE. Copy this path from Artifact Registry. The registry host alone does not include the project ID. To scan an existing version now, enable Run an initial scan. Keep the detected version or enter another tag or digest in Initial scan version. The tag latest is a label, not a guarantee of the newest version. This version selects only the initial scan. It does not restrict which future pushes trigger scans. Listing depends on the provider and the credential permissions. Pull access does not always include listing access. If the registry cannot list images, enter a repository name directly. Browsing and selecting images do not start scans. Adding an image verifies image-read access and stores the detected tag, digest, and platform. This step does not start a scan. Strix uses upload times to choose the newest tagged Google Artifact Registry version. If Google returns a paginated version list, Strix cannot identify the newest image from one page. Strix can still select latest if that tag appears. Otherwise, choose the initial tag or digest yourself. For other registries, Strix uses an existing latest tag or the only available tag. If the registry returns multiple tags without upload times, choose a tag for the first scan. An empty repository can remain tracked for future pushes. For API access, request image names from the selected registry:
The response contains repositories, namespace, and next_cursor. Names do not include a tag or digest. If next_cursor is not null, pass its value as the next request’s cursor parameter. This endpoint requires containers:read and an unscoped admin or analyst role. Docker Hub and GitHub support namespace listing. ECR uses the existing pull role’s ecr:DescribeRepositories permission. Google Artifact Registry uses namespace=PROJECT-ID/REPOSITORY. Other providers use the OCI catalog when the registry supports that catalog. To read image versions before adding the image, call the read-only endpoint:
The response contains available versions and the verified selected tag, digest, and platform. If the registry cannot identify one version, selected is null. This endpoint does not add images or start scans.
The reference field accepts a repository path, name:tag, or name@sha256:<digest>, without the registry host. To track a repository without an initial scan, send its path with scan set to false. Set watch_tags to * to include the new image in its registry’s Auto Scan rule, or null to exclude it. Configure the shared tag rule on the registry, not on each image. The registry_id field is required and must name a connected registry. Strix stores the selected platform on the image. A later scan uses this platform unless the scan request specifies another platform. Set scan to true to start the first scan when the image is added. Strix uses the detected version unless the reference includes an explicit tag or digest. The default is false. The response contains the stored image and any initial scan. The resolved field contains the verified metadata for the detected or explicit version. If no version is available or the registry cannot identify one version, resolved is null. 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.

Scan on image pushes

Automatic scanning needs a registry push connection, the registry’s Auto Scan switch turned on, and included images with tags that match its shared rule. The registry credential lets Strix pull images. The push connection lets your registry notify Strix about new versions.

Set up Auto Scan

After a registry connects, select Set up Auto Scan to open its push delivery setup. Select Done to close the connection flow without configuring Auto Scan. Generic registries use a CI step after docker push instead of a provider webhook. To configure an existing registry:
  1. Open Containers → Registries in the dashboard.
  2. Open the registry action menu.
  3. Select Auto Scan.
  4. If setup opens, follow the provider instructions. Strix prepares the endpoint and secret. For Google Artifact Registry, enter the Pub/Sub delivery service account email and select Save delivery account.
  5. Select Open Auto Scan to manage the registry.
  6. Set Tags to scan in the Auto Scan card and select Save. Use * for all tags or a pattern such as release-*.
  7. Under Images, select which images to scan. Each selected image uses the same registry-level tag rule. Add new images from Containers → Images.
Before the first verified delivery, Auto Scan opens the dedicated provider setup. Configured registries open the management view with the toggle, shared tag rule, and images. Select Edit setup to revisit the provider instructions. Select Back to Auto Scan to return. Turn on Auto Scan in the card when the provider setup is ready. Opening the instructions does not turn on Auto Scan. Turning it off preserves the shared rule and included images. The Delivery verified badge appears after Strix receives an authenticated event while Auto Scan is on. Dialog titles identify the provider, such as Auto scan Docker images. Azure and AWS use one setup step. Google Cloud uses three: create the account, allow authenticated delivery, and configure Pub/Sub. Auto Scan shows Saved only for the editable delivery account after a successful save. Copy-only endpoints, secrets, and headers do not show it. Editing the service account email clears that confirmation until you save it. The modal shows Delivery verified after Strix receives an authenticated delivery. Preparing the setup details alone does not verify delivery. The Registries list separates Connection from Auto Scan. Connection confirms image access. Auto Scan shows Off, On · Setup needed before verified delivery, or On after an authenticated event. Turning on the registry does not include every image. Manage included images in the Auto Scan card. API responses return auto_scan_status, auto_scan_tag_pattern, and auto_scan_image_count. After you add an image, select Scan new pushes to include it in the shared rule. Set the rule in registry settings. The first authenticated push verifies delivery and starts a matching scan. You do not need to send a separate verification notification.

Docker Hub push events

  1. Open Docker Hub → your repository → Settings → Webhooks.
  2. Enter Strix in Name.
  3. Copy the complete Webhook URL from Strix into Docker Hub, including the token query parameter.
  4. Select Create. Repeat for each repository you want to watch.

GitHub Container Registry push events

For an Organization connection, an organization owner opens GitHub organizations → the selected organization → Settings → Webhooks. For a Personal account connection, first connect the package to a repository in GitHub. Open that repository → Settings → Webhooks. You need repository admin access to add the webhook. Use these settings for either account type:
  1. Select Add webhook.
  2. Copy Payload URL from Strix into GitHub. Set Content type to application/json.
  3. Copy Secret from Strix into GitHub. Keep Enable SSL verification selected.
  4. Choose Let me select individual events. Select Packages. Select Add webhook.
The existing Strix GitHub App connection does not configure this webhook.

Azure Container Registry push events

  1. Open Azure Portal → Container Registries → your registry → Services → Webhooks → Add.
  2. Copy Service URI from Strix into Azure.
  3. Copy the full Custom headers from Strix into Azure. The header uses Authorization: Bearer <SECRET>.
  4. Enter StrixPush in Webhook name. Set Location to the registry region.
  5. In Trigger actions, select push. Set Status to Enabled. Leave Scope empty for all repositories.
  6. Select Create.

Google Cloud push events

Image reading and push delivery use different connections. Create a separate account for Pub/Sub delivery. Do not create another JSON key.

Create the delivery account

The Strix dialog shows each field within its setup step. Image access and push events have separate guides.
  1. Open Google Cloud Console. Select the project that contains the Artifact Registry repository.
  2. Open IAM & Admin → Service Accounts → Create service account.
  3. In Service account details, enter Strix push delivery as the name. Keep the generated Service account ID.
  4. Leave the description empty. Select Create and continue.
  5. In Permissions (optional), leave Select a role empty. Select Continue. The delivery account does not need Artifact Registry Reader or Viewer.
  6. In Principals with access (optional), enter your Google Cloud sign-in email under Service account users role. Do not enter the service account email.
  7. Leave Service account admins role empty. Select Done. Do not create a JSON key.
  8. Copy the new service account email from the Service Accounts list.
  9. In Strix, paste that email into Service account. Select Save delivery account.
When you reopen setup, Strix shows the delivery email saved for that registry. The setup modal shows Enabled after an authenticated delivery. The Service Account User role lets your deploying user attach this account to a subscription. Google calls this permission iam.serviceAccounts.actAs. Your deploying user also needs these setup roles on the project, or equivalent permissions:
  • Pub/Sub Admin to create the topic and subscription and grant topic permissions.
  • Service Account Admin to create the account and manage its permissions.
  • Service Usage Admin to enable the APIs and create Google service agents.
These are deployment permissions. Do not grant these administrator roles to the delivery account. Ask your administrator for approved access or assistance.

Copy the setup commands into Cloud Shell

  1. In Google Cloud Console, open the project selector in the top toolbar. Copy Project ID, not the project name or number.
  2. Select Activate Cloud Shell (>_) in the top toolbar. Wait for the terminal at the bottom of your browser.
  3. In the Strix guide, advance to Configure Pub/Sub delivery. Review the commands and the About these commands explanation.
  4. Select Copy commands. Paste the commands into Cloud Shell. Press Enter. No file upload is required.
  5. When the commands ask for Google Cloud project ID, paste the copied ID. If Google requests authorization, select Authorize.
  6. Wait for Push subscription configured.
The commands contain the Strix endpoint and your saved delivery email. They run using your Cloud Shell permissions and read the project number automatically. Cloud Shell includes gcloud. They create no service-account keys and grant Strix no project-wide image access. The script enables the Artifact Registry and Pub/Sub APIs. It creates Google service agents before assigning these resource-scoped permissions:
  • The Artifact Registry service agent gets Pub/Sub Publisher on the gcr topic.
  • The Pub/Sub service agent gets Service Account Token Creator on your delivery account.
The script creates the gcr topic only if needed. It creates a subscription for this registry, or updates that subscription on reruns. Other subscriptions remain unchanged. Official references: create service accounts, authenticated Pub/Sub delivery, Artifact Registry notifications, and Cloud Shell.

Amazon ECR push events

Create the event stack once per connected ECR account and region.
  1. Open the ECR registry’s Auto Scan dialog.
  2. Select Download CloudFormation template. The template creates EventBridge delivery resources and an IAM role limited to sending push notifications to Strix. Save strix-ecr-webhook.json.
  3. Sign in to the registry’s AWS account. Select the registry region shown in the dialog.
  4. Open CloudFormation → Stacks → Create stack → With new resources (standard).
  5. Select Choose an existing template → Upload a template file. Upload the downloaded file. Click Next.
  6. Enter strix-ecr-push as the Stack name. Copy WebhookSecret from Strix into CloudFormation.
  7. Click Next. Leave the optional IAM role under Permissions empty.
  8. Click Next. Review the stack. Acknowledge IAM resource creation. Click Submit.
  9. Wait for CREATE_COMPLETE.
The AWS account ID and region in the guide come from your connected registry hostname. The stack creates an EventBridge rule, an API destination, a connection, and an invocation role limited to that destination. The template masks the webhook secret parameter. The template does not contain the secret. Copy the secret into CloudFormation during stack creation.

Generic registry pushes

  1. Open the CI pipeline that pushes images to the registry.
  2. Save STRIX_PUSH_SECRET from Strix as a CI secret under that name.
  3. Copy the command from the Auto Scan dialog into the pipeline after docker push.
  4. Set IMAGE to the repository path without the registry host. Set TAG to the pushed tag.
The command has this format. Replace <WEBHOOK_ENDPOINT> with the endpoint from Strix.
Strix authenticates the request and uses the saved registry connection to resolve and pull the image. The request can include digest to identify an exact version. Strix ignores events that name another registry host. The command reports notification failures without failing the pipeline. Only tracked images with automatic scanning enabled and matching tag rules start scans.

Configure push delivery through the API

You can also configure a push connection through the API:
For Google Artifact Registry, include google_service_account_email in the request. The response includes the private endpoint, provider instructions, and a setup template when the provider needs one. GET /containers/registries/{registryId}/webhook returns the current settings and delivery status. Setting enabled to true prepares the endpoint to receive events. This setting does not confirm the connection. Automatic scanning requires enabled: true and an authenticated delivery recorded in last_event_at. Save the shared watch_tags on this endpoint. The response includes the rule and each image’s auto_scan_enabled state. Pausing the registry preserves the rule and image selection. The first authenticated matching push can verify delivery and start a scan. Connections saved with an API token check the token’s current scopes, expiry, and revocation on each push. Service tokens do not depend on their creator’s current membership. Both methods require containers:write, because the response includes credentials that can authorize scans. Workspace admins and analysts can configure connections. Asset-scoped members cannot configure connections.

Enable an image

  1. Open the image detail page.
  2. Find Auto Scan above the page tabs. Turn on its switch.
The switch includes or excludes this image from the registry’s shared rule. Turning it on also re-enables a paused image. Set the shared tag pattern in Registries → Auto Scan. All included images use this rule. The Images list shows the shared tag rule, or Off, in the Auto Scan column. Select the value to open the image switch. Off means this image is excluded. Paused by registry means it is included but the registry switch is off. Awaiting first push means delivery is on but unverified. On means delivery is verified and the image is included. You can turn on an image before configuring registry delivery. Open Registries → registry action menu → Auto Scan for delivery settings. Only authenticated push events can start scans. Saving a rule does not start a scan or verify delivery. For API clients, call PATCH /containers/images/{imageId}:
The pattern v* matches tags that start with v. The pattern * matches all tags, including events that contain only a digest. The wildcard ? matches one character. Patterns match the complete tag. Set auto_scan_enabled to false to exclude the image. Manual scans remain available. The legacy watch_tags image field accepts * for inclusion or null for exclusion. Other patterns must match the registry’s shared rule; Strix rejects conflicting per-image rules. Strix uses the event digest when the provider supplies one. Docker Hub sends only a tag, so Strix resolves the tag through the registry. A digest identifies immutable image contents. A tag can point to different contents after another push.
This version does not queue events or deduplicate deliveries. A retry can start another scan after the previous scan finishes. If an image already has a queued or running scan, Strix does not retain the new event for later. The background launch is best-effort. Strix does not retain an accepted event if the process stops before launch.

Start a scan

If the request has no tag, the scan uses the image’s most recent tag or digest. For a repository with no recorded version, supply a tag in the scan request. In the dashboard, Run scan asks for this tag when no saved version is available. Strix does not assume that the repository has a latest tag. 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