Software supply chain security: governed dependencies and verifiable releases
Updated on
Software supply chain governance controls the dependencies, images, AI models, builds, and releases moving through engineering. Automated policies, SBOMs, and evidence define what can proceed to production. Loonar designs and implements those controls, trains teams, and supports ongoing operations, with explicit ownership and exception handling built into delivery workflows.
In short
- Review components before consumption.
- Keep evidence linked to each release.
- Assign ownership to every exception.
How do you know you need software supply chain governance?
Malicious packages at the entry point
A package name that resembles a trusted dependency can lead developers to download the wrong component. Without entry-point curation, malicious code or policy violations reach managed development environments before downstream checks have a chance to respond.
Audit requests without reliable inventories
Auditors ask for software composition and approval records, but the information is scattered across systems. Manually maintained lists age quickly and may not describe the shipped version. Teams must search for evidence and interpret gaps under pressure.
Approvals outside the delivery workflow
Release decisions happen in email or chat without a reliable link to the published artifact. Later, what conditions were reviewed, or whether the authorization still applied when the software was deployed.
Growing scrutiny of software provenance
Customers and regulators may ask how software was built and where its dependencies came from. Without links between commits, and deployments, engineering teams reconstruct delivery history and risk providing incomplete or inconsistent evidence about the product.
How does it work?
Dependency curation before download
Apply origin, and risk criteria where managed environments retrieve dependencies. Block components identified as malicious or outside policy before download, with clear ownership for reviewing blocked requests and exceptions.
Build and release SBOMs
Generate inventories linked to built and distributed versions. Preserve component identities and relevant relationships for exposure queries, while keeping the distinction between a bill of materials and a vulnerability assessment clear.
Signed evidence and attestations
Capture signed statements about build and delivery steps using references such as SLSA and in-toto. Verify identity and integrity before accepting those statements as evidence for promotion decisions or audit review.
Release policies and gates
Set promotion conditions, and exceptions with owners and expiry dates. Automate pipeline checks and give developers useful explanations when a component prevents a release from moving forward.
Commit-to-deployment traceability
Connect source revisions, artifacts, and deployment destinations through consistent identifiers. Support release investigations without relying solely on mutable tags, or conversations between the teams involved.
Audit-ready reporting
Bring inventories, and evidence into accessible reports. Show coverage, and accountable owners so reviewers can understand the scope without treating a tool-generated report as proof of universal compliance.
How does Loonar deliver?
Assess current maturity
Loonar reviews build and dependency practices using SLSA and OpenSSF Scorecard as references. The assessment identifies gaps, and ownership so priorities reflect engineering conditions rather than a generic checklist.
Design workable policies
Agree on provenance, and risk criteria with engineering and security teams. Define decision owners, approval validity, and the evidence needed to justify promotion across the delivery workflow.
Implement gates and evidence
Integrate pipeline gates and configure SBOM and attestation generation. Validate checks against representative workflows, and refine criteria before expanding coverage to additional teams and delivery paths.
Train teams and expose coverage
Teach teams to interpret blocked requests, and request exceptions. Build compliance dashboards that show coverage and gaps clearly, avoiding aggregate indicators that conceal components still awaiting evaluation.
Operate and improve
Review policies, signing practices, and exceptions with accountable owners. Exercise exposure queries, and adapt controls as threats, and applicable obligations evolve over the service lifecycle.
Which technology does Loonar use to deliver it?
What results do we measure?
- Builds with an SBOM
- Track the share of builds with an inventory linked to the produced version.
- Packages blocked at entry
- Monitor components stopped before download and the reasons behind each decision.
- Time to assess a critical CVE
- Measure how long it takes to determine whether products are affected by a critical vulnerability.
- Releases with complete evidence
- Check releases against the full set of evidence required by the agreed policy.
How do SBOM, SCA, and attestations support software supply chain security?
Each mechanism answers a different question and complements the others.
| Aspect | SBOM | SCA | Attestation |
|---|---|---|---|
| Question | What is in this version? | What known risks are present? | How and by whom was it produced? |
| Basis | Component inventory | Components and knowledge sources | Verifiable process statement |
| Use | Locate dependencies | Prioritize risk review | Verify build conditions |
| Limitation | Does not prove safety | Depends on coverage and freshness | Depends on issuer trust |
Where do we apply it?
Financial services
Financial software teams need to link approvals and evidence to the versions they deliver. Governance organizes SBOMs, and exceptions by release to support exposure analysis and audit review. Policies reflect engineering and security responsibilities without replacing an assessment of the contractual and regulatory requirements applicable to each operation.
Healthcare
Applications supporting healthcare services rely on dependencies that change over time. Inventories linked to deployed versions help locate affected components and guide technical review. Build evidence and recorded decisions provide context for updating applications without relying on a manually maintained list that no longer matches the software in use.
SaaS
SaaS teams release frequently and need dependency controls that do not multiply manual approvals. Risk-based gates, and traceable exceptions make rules part of delivery. Release-linked SBOMs and attestations help teams answer customer questions and investigate vulnerabilities across products already running, with clear ownership for follow-up decisions.
Frequently asked questions
What is the software supply chain?
The software supply chain includes the sources, tools, and processes used to build and distribute software. It covers external components and the internal steps that turn source code into a usable release. Loonar designs the controls, trains teams, and supports ongoing governance so decisions and evidence remain accessible across that chain, in proportion to business risk.
What is an SBOM, and when is it required?
An SBOM is a structured inventory of the components in a software version. It helps teams locate dependencies when vulnerabilities emerge and may be requested through contracts, or specific regulatory contexts. Requirements depend on the product, and applicable obligations. SBOM management must keep inventories tied to releases and usable in analysis; an inventory alone does not establish that software is secure.
What is SLSA?
SLSA provides a framework for improving trust in software builds and provenance. It guides controls around the build process and the information used to verify how an artifact originated. Adoption should start with existing gaps and an explicit scope. Using these references does not automatically confer certification or remove every supply chain risk; evidence still needs trustworthy production and verification processes.
How can we block malicious packages before they enter?
Put dependency curation on the retrieval path and restrict routes that bypass it. Check provenance, and usage rules before permitting downloads. Keep exceptions approved, and assigned to accountable owners. Software supply chain security also depends on how completely those paths are covered: no filter can guarantee detection of every malicious package or an emerging threat that has not yet been identified.
Does governance slow developers down?
Poorly placed controls can create waiting and rework. Policies should therefore provide early feedback, and an exception path proportionate to risk. Automating repeatable decisions reduces reliance on approvals through messages, but does not eliminate necessary human judgment. Reviewing blocked requests, and response times helps teams tune software supply chain governance while preserving the evidence required for responsible delivery.
Related solutions
Shall we design the next version of your operation?
Tell us the challenge. One conversation with a specialist gives you a clear path, even if it isn't time to buy yet.