In the modern DevSecOps era, the “shift left” mentality is a standard aspiration. However, as software architectures grow increasingly complex and reliant on external code, the responsibility for security is shifting from a single department to the entire organization.
We spoke with François, a senior product security engineer at Boost Security and co-founder of NorthSec, who has spent over a decade building AppSec programs for both large corporations like Intel and lean startups. François shared his insights on why application security is a shared responsibility, the hidden dangers of development dependencies, and how to evaluate the health of the open-source projects we rely on.
You can read the complete transcript of the epiosde here >
Is Application Security Really a “Developer First” Problem?
A recent industry debate suggests that AppSec is not a developer’s first priority because they are hired to solve engineering problems, not security ones. François refines this perspective: while developers may not be strictly the only ones responsible, security is an overall company responsibility.
- The Problem with Training: You cannot simply provide an OWASP Top 10 training and expect developers to write perfectly secure code immediately.
- The Role of Tooling: Small teams (0-1 security staff) need tools that provide high-confidence results and contextual training “on the job”. Large enterprises require tooling that addresses the “sheer scale” of multiple departments and complex politics.
- The AI Velocity Boost: Technologies like LLMs should not replace analysts but should “extract the know-how” of a security expert to help triage thousands of vulnerabilities quickly.
The Core Challenge: Open-Source Dependencies
“Supply chain security” is a relatively new term for a decades-old problem: depending on code you didn’t write. Today, it is nearly impossible to find software that doesn’t depend on libraries from registries like NPM or PyPy.
The Hierarchy of Inventory
- Banning “Dropped” Jars: The first step is to ban copy-pasting code into your repo without a clear source.
- Manifests: Maintain a clear manifest (e.g., package.json or requirements.txt).
- SBOMs: Move toward official Software Bill of Materials to keep track of the ecosystem.
- Artifact Scanning: Don’t just scan the repo; scan the final production artifact (like a Docker image). These often contain many more dependencies than your source code alone.
The “Hidden” Dev Dependencies
A common oversight is ignoring development scoped dependencies (e.g., linters or test runners). While these don’t run in production, they do run in your CI system. If a dev dependency is compromised, your entire CI pipeline is compromised, and you can no longer trust any artifact produced down the chain.
Threat Modeling the Chain: Introducing SLSA (Salsa)
To assess supply chain security effectively, François recommends the SLSA (Supply-chain Levels for Software Artifacts) model.
SLSA provides a common language for supply chain threats and a tool for compliance.
- Confidence Levels: It ranges from Level 1 to Level 4.
- Level 4 Goals: This represents the gold standard: everything is signed, the build is “hermetic” (isolated), and the environment cannot be modified during the build.
- The Link of Trust: Without digital signatures at each step, you cannot be sure the previous step in the chain is actually what it claims to be.
Navigating the Transitive Rabbit Hole
A significant danger lies in transitive dependencies—the dependencies of your dependencies. This rabbit hole can easily go 10 to 11 levels deep. If any library at level 10 is compromised, the threat moves up the entire chain to your application.
How to Evaluate a New Dependency?
Before introducing a new library, developers should perform due diligence using resources like Google’s deps.dev or the OpenSSF Scorecard. Key metrics to look for include:
- Maintenance Health: Has anyone committed to the code base in the last few years?
- Response Time: Is there a maintainer available to fix vulnerabilities if they are found?
- Security Practices: Does the project use branch protection or require code reviews for pull requests?
- The “Zero Patch” Risk: If a project has a public CVE but is unmaintained, you are stuck with a “zero day” and no path to patch it.
Convincing Management: The Government Impetus
Security is often not seen as a first priority until it becomes a requirement for doing business. François notes that the SolarWinds compromise served as the primary impetus for the US government to take supply chain security seriously.
As a result, coming with an SBOM and proof of due diligence will soon be mandatory for many procurements. This creates a “viral” effect: once a major product used by the government scrutinizes its downstream dependencies, every small open-source project in that chain must meet a higher security bar or be replaced.
Conclusion: Security is a Journey
Building a secure supply chain is a long-term journey, not a one-time activity. It begins with basic inventory and threat modeling and evolves into rigorous verification of the entire build process. By using automated scanners for “low-hanging fruit” like secret detection and leveraging industry frameworks like SLSA, organizations can start building a baseline of trust in the code they ship.
Related Reads
- A Context-Driven Approach to Supply Chain Security
- TLDR Sec Newsletter: The “gold standard” for staying up to date on AppSec and supply chain news.
- deps.dev: Open-source insights for analyzing dependency graphs.
- OpenSSF Scorecard: Automated security health checks for open-source projects.
