Just built a custom policy bundle for our procurement team. Sharing the YAML.

Our procurement team has been scaling up, and with that comes a much more complex web of software licenses and compliance requirements. They were drowning in spreadsheets and manual checks, so we decided to leverage FOSSA to automate their policy enforcement. The out-of-the-box policies are great for engineering, but we needed something tailored for the *procurement* workflow—focusing on vendor approval, commercial terms, and internal compliance gates *before* a purchase order is even cut.

I just finished building a custom policy bundle for them. The goal was to create a clear, automated checklist within FOSSA that procurement officers could run a vendor's software bill of materials (SBOM) against. This gives them a definitive pass/fail with actionable reasons, all based on our internal legal and security mandates.

Here’s a simplified version of the YAML structure we used. The key was breaking it down into clear stages that mirror their review process:

```yaml
# fossa-policy-procurement.yaml
version: 1
policies:
- name: Procurement - Initial Vendor Screening
description: Core commercial and legal checks for any new software vendor.
rules:
- policy: "License must not be AGPL-3.0-only"
action: block
message: "AGPL-3.0 requires special legal review. Route to compliance team."
- policy: "License category must be in ['permissive', 'commercial', 'weak-copyleft']"
action: warn
message: "Strong copyleft license detected. Ensure source distribution terms are reviewed."
- policy: "Dependency must not have critical security vulnerabilities (CVSS >= 7.0)"
action: block
message: "Contains unaddressed critical vulnerabilities. Vendor must provide mitigation plan."
- policy: "Dependency must have a declared license"
action: block
message: "Undefined license. Vendor must provide clear licensing terms."

- name: Procurement - Enterprise Readiness
description: Checks for vendors in final negotiation phase.
rules:
- policy: "Project must have a source code repository available"
action: warn
message: "No source repository provided. May impact security audit capability."
- policy: "Project must have a release within the last 36 months"
action: warn
message: "Potential maintenance risk. Confirm vendor support roadmap."
- policy: "All dependencies must be discoverable (no 'unknown' depth > 2)"
action: block
message: "Supply chain transparency insufficient for enterprise contract."
```

The real power came from integrating this with their workflow. When a vendor submits an SBOM (which we now require), a procurement officer simply uploads it to a shared FOSSA project. The policy evaluation runs instantly. The `block` actions create mandatory to-dos that must be resolved or waived with an audit trail before proceeding. The `warn` actions populate their negotiation checklist.

We’ve already seen it cut down the initial review cycle from days to hours and has made conversations with vendors much more data-driven. They’re no longer just asking "are you compliant?" but can point to specific clauses like "your SBOM shows a GPL-2.0 component, here is our internal policy regarding that, can you address it?"

If you're supporting non-engineering teams with FOSSA, I highly recommend exploring custom policies. It turns a powerful dev tool into a cross-functional compliance engine. I'm curious if anyone else has built policies for finance, legal, or procurement teams and what specific rules you found invaluable.

grace