Software supply chain

Introduction

The platform should make it clear what code, packages, images and tools are trusted enough to become part of the product.

Modern SaaS products are built from many dependencies: application packages, base images, build tools, CI/CD tasks, infrastructure modules and third-party services. The company needs a basic view of where those pieces come from and how they are kept safe.

This is not only a security activity. It is a curation activity. Without regular attention, software quietly drifts into a maintenance trap: dependencies move out of support, runtimes age, hosting platforms change, build pipelines stop working and the team only discovers the problem when an urgent fix is needed.

Why this matters

Supply-chain risk is easy to ignore during a POC because the team is moving quickly. That is fine for experimentation, but by Pilot the product should not rely on unknown packages, unmaintained images or build steps nobody understands.

The goal is not to create a heavy approval process for every package. The goal is to know what is in the product, where it came from, whether it is still supported, how vulnerabilities are found and how fixes are planned. This keeps the product buildable, secure and ready for change.

Detailed decision considerations

• Dependency scanning.
• Container image scanning.
• SBOM expectations.
• Open-source licence awareness.
• Package provenance.
• Base image ownership.
• Patch cadence.
• End-of-support dates for important dependencies, runtimes and platforms.
• Last updated dates for important dependencies, images, modules and services.
• Known vulnerabilities and whether they are exploitable in this product.
• Impact and risk if a dependency fails, becomes unsupported or needs urgent replacement.
• Review dates and owners for the inventory.
• Hosting and platform version lifecycle, including Kubernetes, managed container platforms,

language runtimes, SDKs and CI/CD agents.

• Pre-release, preview, beta or release-candidate dependencies and whether breaking changes could

affect the product or delivery route.

• Security advisory and release-note monitoring.
• Signing or attestation later in maturity.
• Who owns dependency upgrades.
• What happens when a critical vulnerability is found.

Dependency inventory

The dependency inventory should be practical enough to maintain but detailed enough to drive decisions. It should include application libraries, runtimes, base images, hosting infrastructure, platform services, build tools, CI/CD actions and infrastructure modules.

For each important item, record:

• Name and description.
• Current version.
• End-of-support date, where known.
• Last updated date.
• Known vulnerabilities.
• Licence.
• Impact and risk.
• Review date.
• Owner or accountable team.

This inventory forms the basis of the SBOM. The SBOM is not just a compliance artefact; it is a way of making the product understandable when something needs to change quickly.

Lifecycle and update awareness

Supply-chain governance should include a regular lifecycle review. The company should know which versions it depends on, when those versions fall out of support, whether new releases introduce breaking changes and whether preview or pre-release components are being used anywhere in the runtime, build, deployment or infrastructure path.

This includes hosting and platform versions, not just application packages. Kubernetes, AKS, Container Apps, App Service stacks, base images, language runtimes, SDKs, GitHub Actions, Azure Azure DevOps tasks, Terraform providers and infrastructure modules can all introduce security exposure, breaking changes or upgrade deadlines.

Run supply chain security review loop as the regular review process. The loop should feed the weekly security review and produce upgrade actions, accepted risks and escalation items where lifecycle or vulnerability risk becomes material.

Scheduled analysis

Pipeline scanning is useful, but it is not enough. In a startup, a service may sit unchanged for weeks or months while the risk landscape changes around it. Scheduled analysis should run even when no code has changed.

Use scheduled jobs, CI schedules, GitHub Actions, Azure DevOps schedules or a small automation runner to keep the checks alive. Tooling may include dependency scanners, container scanners, Snyk, OWASP Dependency-Check, Dependabot, SonarQube or equivalent tools.

Alerts should be tuned to meaningful thresholds. Too much noise causes people to ignore the process; too little signal means real risk is missed.

Review cadence

The cadence should reflect risk and maturity:

• Critical vulnerabilities or active exploitation signals should be reviewed immediately.
• High-risk dependencies and platform components should be reviewed at least monthly.
• Medium-risk upgrades can normally be reviewed monthly or quarterly.
• Low-risk dependencies can often be reviewed every six months.
• Major migrations and support deadlines should feed annual or quarterly planning.

The cadence is allowed to evolve. The important point is that the decision is explicit and recorded.

Turning findings into work

Supply-chain findings should not stop at a report. End-of-support dates, vulnerability scores, breaking-change notices, licence concerns and impact assessments should become roadmap items.

Prioritise:

• Known vulnerabilities with a real product impact.
• Dependencies or platforms approaching end of support.
• Components with broad blast radius.
• Items that could prevent the product from building, deploying or recovering.

Each significant update should have testing and rollback expectations. This is especially important for runtime, framework, Kubernetes, hosting and database changes where the impact may be wider than a single package.

Adoption model

Start small and make the practice useful before making it formal. A good rollout is:

• Run an initial audit on one repository, module or service.
• Add automated scanning and capture the first dependency inventory.
• Identify unsupported components, painful dependencies and legacy areas causing defects.
• Integrate remediation into normal delivery work.
• Establish recurring review cycles, metrics, documentation updates and ownership.

The business case should be clear: proactive curation reduces emergency upgrades, unsupported surprises, security exposure and the cost of bringing neglected systems back under control. It also helps management understand why some work must be done before it is visibly urgent.

Practical controls

Start with automated scanning in the build pipeline and a scheduled scan that runs even when code has not changed. Make dependency updates visible. Keep base images deliberately boring. Avoid copying random build scripts from the internet without review.

For containers, decide who owns the base image and how it is patched. If every service chooses its own image, patching becomes harder. If the platform provides a small set of approved base images, the team has a clearer control point.

For platform versions, decide who owns lifecycle monitoring. If Kubernetes or a managed hosting stack introduces a breaking change in a preview or upcoming release, the team should know early enough to plan testing, migration and communication rather than discover it during an urgent upgrade.

How this evolves as the company grows

• At POC, know what runtimes, packages, containers and build tools are being used, even if controls are lightweight.

• Before Pilot, dependency and container provenance matter because external users may be exposed to the product.

• At Production, supply-chain review should include hosted platform versions, CI/CD components, container images and infrastructure modules.

• At scale, recurring review should identify breaking changes, end-of-support dates and upgrade risks early enough to plan safely.

What an agent should look for

• Which dependencies and platform versions matter?

• Are support windows and breaking changes tracked?

• Which findings belong in the company risk register?

What good looks like

The company can explain the decision, show the evidence behind it and identify the next point where the control needs to mature.