SBOM Policy Checker

Evaluates bounded inline CycloneDX or SPDX JSON SBOMs against a versioned technical policy and emits normalized JSON, SARIF, hashes, and stable findings. It is built for software-supply-chain teams, security and release engineers, supplier intake operations. The main result is structured, deterministic evidence that can be consumed from the default dataset or an Apify automation.

When to use this Actor

• Gate a supplier SBOM on required provenance and component fields.
• Reject declared denied licenses or package identifiers under a versioned policy.
• Create stable SARIF and normalized JSON evidence for CI or audit trails.

How it works

• Validate CycloneDX JSON 1.5/1.6 or SPDX JSON 2.3 under fixed byte/component/relationship limits.
• Normalize components and relationships, then apply only the explicitly declared technical policy.
• Persist summary/finding rows plus JSON and SARIF reports before emitting the completion event.

The Actor validates only the declared product contract. It does not infer facts outside the supplied data or claim outcomes that the source material cannot prove.

Quick start

1. Open the Actor's Input tab or create a Task from one of the public examples.
2. Paste or adapt this bounded example.
3. Click Start and inspect the default dataset plus the output links shown on the run page.

{
  "items": [
    {
      "id": "supplier-app",
      "sbom": {
        "bomFormat": "CycloneDX",
        "specVersion": "1.6",
        "version": 1,
        "components": [
          {
            "type": "library",
            "name": "clear-widget",
            "version": "2.1.0",
            "purl": "pkg:generic/clear-widget@2.1.0",
            "licenses": [
              {
                "license": {
                  "id": "MIT"
                }
              }
            ]
          }
        ]
      }
    }
  ],
  "policy": {
    "name": "supplier-intake",
    "version": "1.0.0",
    "requireDocumentProvenance": false,
    "requiredComponentFields": [
      "name",
      "version"
    ],
    "deniedLicenses": [
      "GPL-3.0-only"
    ],
    "allowedLicenses": [],
    "unknownLicenseBehavior": "DENY",
    "deniedPurls": [],
    "requireRelationshipIntegrity": false
  },
  "maxSbomBytes": 2000000,
  "maxComponents": 5000,
  "maxRelationships": 10000,
  "maxFindings": 1000
}

Expected result: a completed SBOM summary with stable hashes and no denied-license finding for the MIT component.

Input

The quick-start example is intentionally small. These are the material controls; the Input tab remains authoritative for the complete current schema.

Field	Purpose and format	Default	Important bounds or interaction
items	Independent CycloneDX or SPDX SBOM documents with stable source IDs and inline content or supported source locations.	No implicit default	minimum items 1; maximum items 10
policy	Deterministic component, license, vulnerability-evidence, and relationship rules applied to every submitted SBOM.	No implicit default	See the Input tab for the current schema bound.
maxSbomBytes	Maximum decoded bytes accepted for each SBOM before parsing.	2000000	minimum 1024; maximum 2000000
maxComponents	Maximum component or package records accepted from one SBOM.	5000	minimum 1; maximum 5000
maxRelationships	Maximum dependency or relationship records accepted from one SBOM.	10000	minimum 0; maximum 10000
maxFindings	Caps detailed policy findings after stable ordering while preserving report-level totals.	1000	minimum 1; maximum 1000

Unknown top-level fields and invalid field combinations fail validation rather than being guessed.

Output

The default dataset contains typed records. The run's Output tab links the dataset and any key-value-store reports declared by the current output schema.

Field	Meaning
recordType	Identifies SBOM summary, finding, or error evidence.
sbomId	Current dataset field.
format	Current dataset field.
specVersion	Current dataset field.
status	Current dataset field.
componentCount	Current dataset field.
relationshipCount	Current dataset field.
findingCount	Current dataset field.
findingsTruncated	Current dataset field.
policyName	Current dataset field.
policyVersion	Current dataset field.
policyHash	Hash of the exact policy evaluated.
inputHash	Current dataset field.
findingCode	Current dataset field.
severity	Current dataset field.
componentId	Current dataset field.
path	Current dataset field.
message	Current dataset field.
fingerprint	Current dataset field.
errorCode	Current dataset field.
errorMessage	Current dataset field.
jsonReport	Current dataset field.
sarif	Portable SARIF 2.1.0 representation of the findings.
engineVersion	Current dataset field.

Representative current-schema dataset item:

{
  "recordType": "sbom",
  "sbomId": "supplier-app",
  "format": "CycloneDX",
  "specVersion": "1.6",
  "status": "PASSED",
  "componentCount": 1,
  "relationshipCount": 0,
  "findingCount": 0,
  "findingsTruncated": false,
  "policyName": "supplier-intake",
  "policyVersion": "1.0.0",
  "policyHash": "example-policy-hash",
  "inputHash": "example-input-hash",
  "engineVersion": "1.0.0"
}

An SBOM with no components is evaluated against the declared provenance, field, and relationship policy; it is not automatically treated as useful or complete.

Pricing and billing

This Actor uses PAY_PER_EVENT; platform usage is included in event prices. A charge is eligible only after the billable unit described below is durably completed. Validation failures and the non-billable failure classes in the product contract do not emit the custom completion event. Higher Store tiers use the complete tier matrix below; Platinum and Diamond match Gold under the current policy. The Apify Pricing tab is authoritative if a later approved pricing change takes effect.

Event	What triggers it	FREE	BRONZE	SILVER	GOLD	PLATINUM	DIAMOND
sbom-policy-evaluated	One readable supported SBOM evaluated to a final PASS or FAIL verdict after durable evidence.	$0.05000000	$0.04750000	$0.04500000	$0.04250000	$0.04250000	$0.04250000
apify-actor-start	Platform-managed Actor start event.	$0.00005000	$0.00005000	$0.00005000	$0.00005000	$0.00005000	$0.00005000

The Actor does not have Task-specific prices: public Tasks use this same live Actor pricing. Third-party costs are not implied; see the data and security section for external services actually contacted.

Limits and bounds

• Only inline CycloneDX JSON 1.5/1.6 and SPDX JSON 2.3 are supported.
• Current schema bounds bytes, components, relationships, and findings; callers may select lower limits.
• The runtime is offline and does not fetch schemas, vulnerability databases, repositories, or container images.

These are product-facing limits, not targets. Use smaller inputs when you need faster feedback or simpler evidence.

Failure and edge-case behavior

• Malformed, unsupported, or over-limit SBOM input fails closed and produces explicit error evidence.
• Policy violations are completed evaluations with findings and a failed policy status, not Actor crashes.
• Unknown licenses follow the policy's explicit behavior and are not guessed.

Operationally:

• Version each policy and retain policyHash/inputHash with release evidence.
• Use findingsTruncated and findingCount together when maxFindings limits dataset rows.

Use with Tasks and automation

Public Tasks provide reusable saved inputs for distinct supported workflows. Start with the closest Example Task, review its visible fields and scope caveat, then save your own Task for schedules or repeated runs. Do not treat an Example Task as evidence that unsupported behavior exists.

• Gate a synthetic supplier SBOM: Evaluate one synthetic supplier CycloneDX SBOM for required provenance, relationship integrity, and denied licenses.
• Block an SPDX release on a denied license: Evaluate a synthetic SPDX 2.3 release SBOM and retain deterministic FAIL evidence when GPL-3.0-only violates the release policy.
• Triage a mixed SBOM intake batch: Evaluate synthetic CycloneDX and SPDX supplier SBOMs in one batch while isolating an unsupported document as non-billable ERROR evidence.

Integration and API usage

Every saved Task can be started manually, through the Apify API, or from an Apify schedule. Run-completion webhooks can notify a downstream system after output is durable. Actor-to-Actor calls should consume the typed dataset/output links instead of scraping the Store page.

• Consume SARIF in code-scanning workflows and normalized JSON in release evidence.
• Use a Task for each stable policy version and start it from CI through the Apify API.

No third-party integration is claimed unless it is named above and supported by the current product contract.

Data, privacy, and security

• SBOMs and reports remain in Apify run storage under account retention settings.
• No external service is contacted and no repository credential is required.

Set Apify storage retention and access according to the sensitivity of your inputs and outputs. This documentation does not create legal, privacy, compliance, or security certification.

Support and known limitations

• The Actor does not query vulnerabilities, validate attestations, scan source/images, or prove component presence.
• License findings are technical policy evidence, not legal or compliance conclusions.

For support, use the Actor Issues page. Include the run ID, a minimal reproducible input with sensitive values removed, the failing record or error code, and what you expected. Do not post credentials, private source files, customer data, or full confidential payloads.