Software Supply Chain Security: Risks, Controls, and Testing

Software supply chain security is the practice of reducing risk across the software, people, services, and processes used to build and deliver an application. For SaaS security and engineering leaders, that means looking beyond the code your team writes. An application also depends on libraries, source repositories, build systems, CI/CD workflows, cloud services, vendors, and the identities that connect them. A weakness in any link can affect what reaches production.

Talk with Penti about application security testing

What does software supply chain security cover?

The software supply chain is the chain of inputs and actions that turn source code into software users can run. It includes first-party code and third-party components, but also the infrastructure and permissions involved in building, signing, storing, and deploying a release.

This wider view matters because a secure application can still be exposed through a compromised dependency or a build workflow with excessive access. Likewise, a vendor may introduce risk through a product, integration, hosted service, or update process. Software supply chain security asks teams to understand those connections, decide which ones matter most, and apply controls that fit the risk.

It is related to, but not the same as, application security or vendor risk management. Application security focuses on weaknesses in an application and its design. Vendor risk management considers outside organizations and services. Supply chain security connects these areas to the full path from a software component or change to a production system. Teams can use a third-party risk management framework to structure vendor reviews, then examine the technical paths those vendors and components can reach.

Where can supply chain risk enter a SaaS environment?

Start by mapping the components and transitions that matter to a release. The goal is not to assume every dependency or supplier is equally dangerous. It is to identify where a compromise, mistake, or unreviewed change could affect confidentiality, integrity, availability, or customer trust.

Open-source and commercial dependencies

Modern applications often rely on packages maintained outside the organization. Risk can come from a vulnerable version, a malicious or compromised release, a dependency that is no longer maintained, or confusion about which package is actually in use. Transitive dependencies add another layer: your team may not select a package directly, yet it can arrive through another library.

Maintain a current inventory of components and their versions. Use dependency review and update controls that fit your release process. Prioritize components based on where they are used, what access they have, whether a relevant weakness is known, and how quickly your team can patch or replace them. An inventory is a starting point, not proof that a component is safe.

Source code and contributor access

Repositories hold the source and configuration that determine what a build will produce. Risk can arise from stolen credentials, overly broad permissions, unreviewed changes, exposed secrets, or weak protection for important branches. Review who can write code, approve changes, alter workflow definitions, and manage repository settings. Require strong authentication and limit privileged access to the people and systems that need it.

Consider the entire change path, not just the application code. A change to a build file or deployment workflow can alter how software is assembled or where it is sent. Protect those files with review and approval rules similar to the ones used for sensitive application changes.

Build systems and CI/CD workflows

Build infrastructure processes source code and often holds credentials for registries, cloud platforms, or deployment environments. If a workflow can access more secrets or environments than it needs, a compromised account or malicious change may have a larger impact. Separate duties where practical, limit token permissions and lifetime, and keep production credentials out of routine build steps unless they are necessary.

Also examine third-party actions, plugins, runners, and reusable workflow templates. Pin and review them according to your organization’s policy. Keep build environments controlled, monitor changes to workflow configuration, and define how a release is approved and promoted. For teams strengthening pipeline practices, DevSecOps workflow guidance can help connect security checks to software delivery without treating them as a final gate only.

Artifacts, registries, and deployment

A release artifact should have a clear origin and controlled path to production. Teams need to know which source revision produced it, where it was stored, who can replace it, and what checks occur before deployment. Restrict write access to artifact repositories, protect release credentials, and avoid rebuilding an already approved release from different inputs without recording that change.

Where your release process supports it, preserve provenance information and verify signatures or other integrity controls. These measures help answer practical questions during an incident: which component or build is affected, what release contains it, and which customers or environments received it?

Vendors and hosted services

External providers can be part of the software supply chain even when your team never receives their source code. SaaS integrations, managed build platforms, code hosting, cloud services, and security products may hold data or permissions that affect your systems. Assess each provider in context. A tool with read-only access to public data has a different exposure from one that can deploy production code or retrieve secrets.

Document the service’s purpose, data handled, connections, access level, and business dependency. Review security information and contractual commitments that are relevant to your use case, and decide who owns follow-up when a provider changes its service or reports an incident. A vendor questionnaire alone cannot show every technical path into your environment.

How can a team prioritize supply chain controls?

There is no single control that removes supply chain risk. A workable program layers visibility, access limits, verification, and response. Begin with a manageable scope, such as the production application and the build path that deploys it. Expand the inventory as teams identify important dependencies and services.

Use the table as a planning aid, not a compliance checklist. The right sequence depends on your architecture and exposure. A small team might first revoke stale credentials, add review protections to deployment workflows, and identify critical production dependencies. A larger organization may need ownership and evidence processes across multiple engineering groups.

For a more formal program, compare your practices with authoritative guidance. NIST software supply chain security guidance discusses software as part of the broader cybersecurity supply chain. CISA guidance for software customers covers practices for procuring and deploying secure software, including use of a Software Bill of Materials. These resources can inform internal policy, but teams should map recommendations to their own systems and risk decisions.

How should teams use a Software Bill of Materials?

A Software Bill of Materials, or SBOM, is a structured inventory of software components. It can help an organization understand what is included in a product and investigate whether a component may be relevant when new information emerges. It is especially useful when it is accurate, tied to a specific product version, and maintained through the release process.

An SBOM is not a security verdict. It does not establish that listed components are free of vulnerabilities, that a build was protected, or that a package was not tampered with. It also cannot replace ownership, patch decisions, access controls, or testing. Treat it as one source of visibility that supports questions such as:

• Which released versions include a component that needs review?
• Which team owns the component and can assess an update?
• Does the component run in a sensitive service or hold meaningful permissions?
• Can the team update or mitigate it without disrupting a critical workflow?

Pair the inventory with a process for receiving vulnerability information, assessing applicability, assigning an owner, and tracking remediation. An inventory that nobody uses quickly becomes stale. For broader context on application weaknesses and risk categories, see Penti’s guide to the OWASP Top 10 risks and testing priorities.

Where do penetration testing and continuous validation fit?

Supply chain controls protect the path software follows, but they do not prove that the resulting application is secure. Penetration testing adds a different kind of evidence by examining whether weaknesses in a defined scope can be reached and exploited. It can help reveal how a defect in an application, an exposed service, or an integration behaves in context.

Testing should complement, not replace, dependency inventory, secure repository practices, protected build workflows, and vendor review. A penetration test is also bounded by its scope and timing. It cannot establish that every dependency is safe or that every future release will remain secure. Teams should define the application, environments, access assumptions, and test boundaries before work begins.

Use testing at meaningful points in the delivery lifecycle. A significant application change, a new integration, or a change to an exposed service may justify a focused assessment. Regular testing can provide another check as the product changes. Continuous security assurance or on-demand approaches may help teams validate changes more often, while human review can add context to findings. Learn more about Penti’s AI penetration testing and the distinction between continuous and periodic penetration testing.

For each finding, record the affected component or service, the evidence, the likely impact, the owner, and the planned fix. Retest after remediation to check whether the issue is resolved and whether the fix introduced a new weakness. When a finding traces to an external component, coordinate the upgrade or mitigation with the team responsible for that dependency. This turns testing into a feedback loop rather than a report that sits apart from engineering work.

Teams seeking information about Penti’s security posture can also visit the Penti Trust Portal. Review the materials relevant to your evaluation and ask questions about how they apply to your requirements.

What can a supply chain failure look like in practice?

Concrete scenarios make it easier to test whether safeguards match the risk. For example, a package update could introduce a vulnerability that affects a feature your application exposes. The first useful questions are not only whether the package appears in an inventory, but whether the affected version is deployed, which services use it, and whether the vulnerable behavior is reachable in your configuration. A clear owner and an update path help the team move from alert to a decision.

In another scenario, a compromised developer credential could be used to make an unauthorized repository change. Review protections, strong authentication, limited permissions, and alerts for sensitive changes can reduce the chance that one account has unchecked control. If a change does reach a build, traceability between source revisions, build records, artifacts, and deployments helps the team determine what needs investigation or replacement.

A third scenario involves an integration or vendor whose access expands over time. A service initially connected for a narrow purpose may later gain broader permissions or handle new data. Record why each integration exists, which identities it uses, and who approves permission changes. Revisit the record when the service or business use changes. This is more actionable than treating every provider as an identical checkbox in an annual review.

For each scenario, decide in advance who triages the issue, who can halt or roll back a release, how engineering communicates affected versions, and who verifies the remediation. The response does not need to assume a breach occurred. It needs a reliable way to establish what is known, what remains uncertain, and what action is proportionate. These exercises also expose missing ownership or inventory information before an urgent event makes those gaps harder to resolve.

How can a SaaS team start without overbuilding the program?

A practical first pass can fit into existing security and engineering routines. Assign an owner, select a critical application, and trace one representative change from code to production. Use what the exercise reveals to prioritize improvements rather than launching a broad process with no clear purpose.

1. Map the release path. Identify repositories, package sources, build services, artifact stores, deployment identities, and third parties involved in a production release.
2. Find high-impact access. Look for accounts or workflows that can modify code, retrieve secrets, publish artifacts, or deploy to production. Remove access that is not needed and assign owners to exceptions.
3. Improve component visibility. Establish how the team tracks direct and transitive dependencies and how it decides whether an update is urgent.
4. Protect sensitive changes. Add review and approval controls for code, workflow configuration, and release settings that can alter the production path.
5. Test the application in context. Use a defined scope to assess whether weaknesses in exposed application paths can be exploited, then connect findings to remediation owners.
6. Exercise response. Walk through how the team would identify affected releases, communicate internally, update a component, and confirm the fix.

Keep a short record of decisions and gaps. Useful measures are operational rather than vanity counts: whether critical components have an owner, how quickly the team can determine affected releases, whether deployment permissions are reviewed, and whether important findings are closed and retested. These measures help leaders see whether controls work in practice without implying that risk has disappeared.

Discuss a penetration testing plan for your application

Frequently asked questions

Is software supply chain security only about open-source packages?

No. Dependencies are one part of the picture. The scope also includes source code, build and CI/CD systems, identities, artifacts, deployment processes, and third-party services that can affect software or its delivery.

Does an SBOM prove that software is secure?

No. An SBOM can help identify components in a product version, but it does not prove that those components are safe, that the build was protected, or that the finished application has no exploitable weaknesses. It works best alongside controls and an active review process.

Can penetration testing replace supply chain controls?

No. Testing can provide evidence about weaknesses in a defined application scope, but it does not replace component inventories, access management, build protections, or third-party oversight. Those controls address different parts of the risk.

How often should a SaaS company review its software supply chain?

Review it when meaningful changes occur, such as adding a critical dependency or vendor, changing the build or deployment path, or introducing a new production integration. Teams should also define a recurring review cadence that fits their risk and release model.

Software supply chain security is an ongoing engineering and security practice: know what enters a release, protect how it is built, limit who and what can change it, and validate the application as it evolves.