Part 2 - Control: Making the Secure Path the Default Path

Most teams believe they have OSS risk under control because they run vulnerability scans. The scanner flags a CVE, a ticket gets created, engineering patches when the sprint allows, and the cycle repeats. That is not control. That is a scheduled reaction to problems that have already entered the environment.

Control means the question is asked before the package arrives - not after it is already running in production.

This is Part 2 of A Practical OSS Management Framework - a four-part series on building a complete OSS security operating model. Part 1 covered Visibility. Part 3 covers Scale.

From Inventory to Enforcement

Part 1 established what visibility means: a reliable, continuously updated inventory of every component in the environment, with ownership metadata attached. Visibility is the prerequisite. Control is what makes it operationally useful.

The shift from visibility to control is architectural. It requires three things working together:

• A machine-readable artifact that captures what is in each component - the SBOM

• A pipeline trigger model that determines when and where checks run

• A gating mechanism that enforces policy before code reaches production

Each of these is a design decision, not a tool selection. The tools follow the decisions.

The SBOM: Making Inventory Machine-Readable

A Software Bill of Materials, or SBOM, is a structured, machine-readable record of every open-source component in a given artifact - its name, version, license, and origin. It is what turns the component inventory from a human-readable register into something downstream controls can query automatically.

Two formats dominate the space: SPDX and CycloneDX. Both were evaluated. Syft, the generation tool used across component types, produces both the formats and the outputs are inter-convertible. CycloneDX was retained as the standard format. The deciding factors were toolchain compatibility across the full component surface and directional alignment with the broader BOM ecosystem - CycloneDX's extensibility toward hardware, AI/ML, and SaaS dependency modeling made it the more forward-looking choice for a program that was not planning to stop at software.

The SBOM is an internal operational artifact at this stage. Raw SBOM files were consumed by the product security team, not distributed externally. The value is not the file - it is what the file enables downstream: automated vulnerability matching, license classification, and policy enforcement without manual inspection.

One scoping decision shaped everything else: if it does not ship, it does not count. Build-time and test-time dependencies are tracked separately. The production SBOM covers only what runs in the artifact. That boundary keeps the SBOM useful during incident response, when a bloated file covering build tooling alongside production packages slows down the exact query it is supposed to answer instantly.

The Pipeline Trigger Model

Knowing when to generate and when to enforce are separate decisions.

• Generation runs on every build. Every build produces a current SBOM for that artifact at that commit. This keeps the inventory continuously fresh without requiring manual updates.

• Sync to the central intelligence layer runs on release branches only. Release branches are the boundary between development and production-bound code. Syncing on release ensures the intelligence layer reflects what is actually heading toward customers - not every experimental branch or work-in-progress build.

• Gating runs on every merge request, across all repositories, from day one. There is no phased rollout, no grace period for specific teams. The decision was made jointly with engineering and leadership before rollout: an unapproved package should have no path to production, not even a slow one. The gate is the enforcement point. The exception process is the safety valve.

The Gate: Compass First, Block When Necessary

The MR gate is where policy becomes enforcement. But a gate that only blocks produces one thing reliably: workarounds.

The design principle carried through every enforcement mechanism in this program: security acts as a compass wherever it can, and only as a gate where it must. The MR gate reflects that in its exception model.

When a package fails the gate, the outcome depends on why it failed:

• Policy violations - unapproved package, unknown license: The MR is blocked. The developer is routed to the approval process.

• Vulnerability findings: A risk exception is opened. The exception window is set by criticality - a critical CVE gets a shorter window than a moderate finding. The exception is tracked in the OSS risk register with an explicit expiry date.

• Transitive dependencies that cannot be directly controlled: Product security evaluates the engineering team's argument for mitigation. If accepted, the dependency is marked mitigated in the risk register. It is not ignored - it is a tracked state with a clear owner.

The risk register is the governance backbone of the exception model. Every open exception, every mitigation, every expiry date lives there. When an exception expires, the flag surfaces automatically. The gate re-evaluates. The exception either gets renewed with fresh justification or the package gets remediated.

This is not bureaucracy. It is what makes the gate trustworthy to both engineering and leadership - engineering knows there is a route through, and leadership knows every route is logged and time-bounded.

The Compliance Signal

The control layer is where regulatory expectations become engineering reality. SBOM generation - required or strongly expected under frameworks like NIST SP 800-218, Executive Order 14028, and the EU Cyber Resilience Act - is not a reporting artifact here. It is the operational input to every downstream control. The program produces SBOMs because the program needs them, not because an auditor asked for them. That distinction matters when an audit does arrive: the artifacts exist because the engineering model demands them, which is a far stronger posture than producing them on request.

Key Takeaways

• Scanning for CVEs after deployment is not control. Control means the policy question is asked before the package enters the environment.

• CycloneDX was chosen over SPDX for toolchain fit and directional extensibility - the decision was made after validating inter-operability, not by default.

• Generate SBOMs on every build. Sync to the intelligence layer on release branches. Gate on every MR. These are three separate decisions with three separate rationales.

• The exception model is what makes the gate sustainable. Time-boxed exceptions with criticality-based expiry and a tracked risk register give engineering a governed route and give leadership a complete audit trail.

• Roll out gating to all repositories from day one. A phased rollout creates coverage gaps and signals that some paths to production are safer than others.

What's Coming Next

Control establishes the enforcement boundary. In Part 3, the question shifts to scale - how vulnerability analysis, license classification, health scoring, and the OSS intelligence layer work together to make the program useful across many teams, many artifact types, and a dependency graph that never stops growing.

If you missed Part 1, read it here: Part 1 – Visibility: The Operating Model Starts Here