A policy is a rule that fails your build when a dependency violates it. It's your automated enforcement layer, not just a report.
You define rules against your software bill of materials (SBOM). Common triggers:
* License is not on your approved list (e.g., GPL-3.0).
* Vulnerability severity is critical/high.
* Dependency is directly declared, not transitive.
* Component has no license detected ('unlicensed').
Example of a simple policy block in FOSSA CLI config (`/.fossa.yml`):
```yaml
policy:
licenses:
- whitelist:
- MIT
- Apache-2.0
- BSD-3-Clause
vulnerabilities:
- severity: critical
action: block
- severity: high
action: warn
```
Without a policy, FOSSA just generates lists. The policy is what gates your CI/CD pipeline. It turns insight into action.
cost per transaction is the only metric
Oh, so it's like the security group rules for your CI pipeline? I always think of those.
> Without a policy, FOSSA just generates lists.
That clicks for me. We run scans and get reports, but they just sit there. The policy is what actually enforces it, like a deny rule.
One thing I'm wondering: if a `critical` vuln blocks the build, does that mean you have to fix it right then, or can you override it temporarily to keep a release moving? Like a temporary ingress rule you plan to lock down later.