With open-source components making up 85–97% of enterprise codebases, software supply chain security has moved from a niche concern to a board-level priority. High-profile attacks on SolarWinds and others have shown that a single compromised dependency can cascade across an entire ecosystem.
We spoke with Htet Naing Aung, a cybersecurity expert and Principal Security Architect at a global infrastructure services company, on the Scale to Zero podcast. With over 12 years of experience spanning financial institutions, banking, and system integrators — including a stint at Standard Chartered Bank as a cloud application and container security SME — Aung brings deep expertise in DevSecOps, container orchestration security, and zero trust architecture.
You can read the complete transcript of the episode here >
What is software supply chain security and why does it matter?
Software supply chain security encompasses the measures and practices that safeguard the integrity, confidentiality, and availability of software throughout its lifecycle — from development to deployment and ongoing maintenance. It ensures that components, libraries, dependencies, and updates remain free from vulnerabilities and malicious code.
Aung highlights several reasons organizations must prioritize it:
- Risk mitigation: Components sourced from various vendors can introduce vulnerabilities across an entire ecosystem.
- Data integrity: Attackers target supply chains to inject malware, compromise code integrity, or introduce backdoors.
- Business continuity: A breach in the supply chain can lead to service disruptions, financial losses, and reputational damage.
- Compliance: Regulations like NIST, GDPR, and federal standards increasingly require supply chain security controls.
How should a first-time security leader tackle supply chain challenges?
For leaders just getting started, Aung recommends a structured approach:
- Understand SBOMs: A Software Bill of Materials acts as a manifest detailing all components within your software stack. It is the foundation for identifying vulnerabilities and dependencies.
- Conduct risk assessment and inventory management: Map all open-source and third-party components in your codebase to understand your exposure.
- Establish security policies: Define policies for vetting and monitoring components, including regular vulnerability assessments.
- Implement continuous monitoring: Stay current with security advisories and patches from vendors and the open-source community.
- Build vendor collaboration: Work with suppliers to ensure they provide SBOMs and adhere to security best practices.
How do you analyze SBOMs without getting overwhelmed?
When dealing with SBOMs from dozens of vendors, the starting point is integrating analysis into your CI/CD pipeline. Aung recommends:
- Implement Software Composition Analysis (SCA) tools that identify and manage vulnerabilities within your supply chain automatically.
- Adopt SBOM standards like SPDX or CycloneDX to normalize data across vendors.
- Combine with static and dynamic scanning in your pipeline for comprehensive coverage.
- Educate teams on secure coding practices and why supply chain security matters.
- Establish an incident response plan tailored specifically to supply chain breaches.
This approach transforms raw SBOM data from an overwhelming dump into actionable intelligence that feeds procurement, vulnerability management, and incident response processes.
What is container image signing and why is it critical?
Container image signing involves digitally signing container images to verify their integrity, authenticity, and provenance throughout the development lifecycle. It serves three purposes:
- Security assurance: Verifies that an image has not been tampered with before deployment into a runtime environment.
- Trust and compliance: Confirms the authenticity and origin of images, aligning with industry standards.
- Risk mitigation: Provides a secure way to manage images, reducing vulnerabilities in the software supply chain.
Key signing methods include Docker Content Trust (using cryptographic signatures with root and per-repository keys), the TUF framework (a decentralized approach to signing and verification), and tools like Cosign from the Sigstore project.
What are the best practices for container image signing?
Aung outlines several best practices for implementing image signing effectively:
- Use a trusted registry: Adopt registries that support signing capabilities, such as Docker Registry or JFrog Artifactory.
- Implement key management properly: Use solutions like AWS KMS or HashiCorp Vault for secure key storage, rotation, and access control.
- Automate signing in CI/CD: Integrate signing seamlessly into pipelines so it does not slow down the build process.
- Enforce policies with OPA: Use Open Policy Agent to block unsigned images from running in production — if an image is not from a trusted source, it cannot deploy.
- Monitor continuously: Regularly validate signed images for anomalies or tampering.
The overarching principle: do the basics right. Proper key management, automation, and policy enforcement form the foundation regardless of which specific signing tool you choose.
How should organizations integrate code signing into CI/CD pipelines?
Integrating code signing into CI/CD requires a thoughtful approach:
- Automate the signing process so it happens as a natural step in the pipeline, not a manual gate.
- Store cryptographic keys securely in a compliant key management system, separate from the code repository.
- Define approval workflows with clear guidelines on when and how code should be signed.
- Maintain a secure artifact repository for signed artifacts with access controls.
- Document and train teams on the process, including what minimum standards must be met before promoting to production.
The goal is making security invisible to developers while maintaining strong guarantees about code integrity and container runtime security.
