Policies & Evaluations
Understand how SBOM policies work and how they are evaluated.
Making Findings Actionable
You've uploaded your SBOMs to SBOM Observer. Now you see thousands of vulnerabilities across your software supply chain. Which ones matter? Which can wait? How do you decide what to fix first?
This is where policies come in.
A policy is simply a rule that says: "This matters to us." Instead of treating all vulnerabilities equally, policies let you define what actually threatens your organization. That critical CVE affecting only dev dependencies? Probably not urgent for production. That missing SBOM metadata? That violates your compliance requirements.
Policies transform raw vulnerability data into business decisions. To see the exact objects a policy reads, check the Data Model Fundamentals overview.
Why Policies Matter
Imagine two scenarios:
-
Without policies: Your team sees 500 vulnerabilities. The CISO asks "Are we safe?" The answer is unclear because you don't know which vulnerabilities actually matter for your business.
-
With policies: The same vulnerabilities exist, but policies filter them to 12 violations. The CISO asks "Are we safe?" The answer is clear: "Yes, except for these 12 specific issues that violate our standards."
Policies work because they encode your organization's actual risk tolerance. You decide what's acceptable. Then policies enforce it automatically.
This is especially powerful for regulatory compliance. Instead of manually checking SBOMs against CRA, NIS2, or DORA requirements, policies continuously verify compliance whenever an SBOM is uploaded, when components change in your workspace, or when new vulnerabilities are detected.
How Policies Work
The flow is simple:
- You define a policy: "Production code must not have unresolved critical vulnerabilities"
- An SBOM is uploaded to SBOM Observer
- The policy automatically evaluates every component
- Violations are recorded if any component violates the policy
- Your team sees actionable violations, not noise
This happens continuously. Every time vulnerability data updates or a new SBOM arrives, policies re-evaluate. Your compliance posture is always current.
Policy scopes
- SBOM-level policies look at an entire bill of materials. They answer questions like “Does this upload include the metadata we require?” or “Are production SBOMs missing supplier attestations?”
- Vulnerability-level policies evaluate each finding tied to a component. They decide whether a specific CVE (plus its VEX context, namespace, etc.) is acceptable or must block the build.
Both scopes run during the same evaluation cycle, so you can enforce structure and content simultaneously.
Coming soon
A third policy scope will target policy violations themselves—think “policy for policies.” These meta-policies will watch the violation stream so you can automate whatever follow-up standards you define.
Enforcing standards in CI/CD
Policies can act as automated gates in your build and release pipelines. Instead of relying on manual checks, non-compliant builds fail fast with clear reasons.
Developers receive immediate feedback, keeping issues left-shifted and cheaper to fix, and preventing non-compliant artifacts from reaching production.
Two Ways to Author Policies
You can create policies two ways:
-
Visual Builder is for teams who want simplicity and speed. No code required — just point and click to define your rules. Perfect for getting started or covering your basic security needs quickly.
-
Policy as Code (Rego or JavaScript) is for teams who need complex logic, version control, and portability. Write policies as code, commit them to Git, review changes in pull requests. Perfect for organizations with sophisticated compliance requirements or teams that prefer DevOps workflows.
Both approaches do the same thing — they prevent non-compliant code from reaching production. Choose based on your team's preferences and complexity needs.
One-way conversion
If you start in the Visual Builder, you can convert a policy to code once. Conversion is not reversible. If you may need both, keep a copy before converting.
The Practical Outcome
Policies answer the essential question: what matters for this organization?
Without policies, security is a count of findings. With policies, security becomes a set of violations tied to defined standards. That clarity helps leaders understand exposure, guides developers on what to fix, and demonstrates commitments to customers and auditors.
Policies turn detection into governance.
Next Steps
Ready to create policies? Start with the First Policy tutorial for a hands-on walkthrough in a couple of minutes, or dive into the Write and test policies guide for detailed examples of each approach.