Understanding the Problem
In recent weeks, I've been involved in several incident channels where teams discovered issues in their software supply chain. One team found API keys in a contractor's public repository. Another realized their build pipeline was using an unmaintained package with known vulnerabilities. A third team faced a leak from a vendor they rely on, reminiscent of the recent Claude source code incident.
In each case, similar questions arise. Here’s what teams typically ask when confronting a supply chain problem and what you need to know.
Q1: "We Just Found Out a Dependency Leaked Source Code. Are We Required to Report This?"
Your reporting obligations depend on the data you handle and the frameworks you adhere to.
If you're PCI DSS compliant, Requirement 12.10.1 mandates an incident response plan that includes third-party service providers. If the leaked code could expose cardholder data, reporting is necessary.
For SOC 2 Type II, your incident response procedures (CC7.3) must cover third-party incidents affecting service commitments. If this dependency processes customer data or affects availability, document your response.
The key question: Can you show that you assessed the impact and took action? Document your analysis. What was in the leaked code? Does it contain credentials or reveal architectural details that increase your attack surface? Answer these questions first, then determine reporting obligations.
Q2: "How Do I Know If We're Even Using the Compromised Component?"
You need a Software Bill of Materials (SBOM) and should have had it before this incident.
Start with your dependency management tools. For Node.js, run npm list or check package-lock.json. For Python, use pip freeze or inspect your requirements.txt. For Java, use Maven's dependency tree or Gradle's dependencies task. These tools show direct and transitive dependencies.
However, you might be using the component in more places than your package manager knows. Check:
- Container images (scan with Syft or Trivy to generate SBOMs)
- Build tools and CI/CD plugins
- Developer workstations
- Infrastructure-as-code dependencies
OWASP ASVS Requirement 14.2.1 requires maintaining a catalog of third-party components. If you can't answer "where do we use this?" quickly, you're not compliant and will face challenges in future incidents.
Q3: "Can We Just Update to the Patched Version and Move On?"
Not without testing, and probably not as quickly as you'd like.
Your incident response plan should define your change management process for emergency updates. PCI DSS Requirement 6.5.3 requires testing security patches before deploying to production, even in emergencies.
Here's a realistic timeline:
- Hour 0-2: Confirm the vulnerability affects you.
- Hour 2-4: Pull the patched version into a staging environment.
- Hour 4-8: Run automated tests, check for breaking changes.
- Hour 8-12: Deploy to production with a rollback plan ready.
If you lack staging environments or automated tests, you're making a risk decision: Deploy untested and risk breaking production, or leave the vulnerability exposed while testing manually. This is why ISO 27001 Control 8.31 exists.
Q4: "What If There's No Patch Available Yet?"
Implement compensating controls while you wait, and document everything.
Immediate actions:
- Can you firewall off the affected component?
- Can you increase monitoring and add logging around calls to the vulnerable component?
- Can you reduce exposure by taking the affected service off the public internet?
For PCI DSS environments, Requirement 6.4.3 requires addressing critical vulnerabilities within one month. Document compensating controls and risk acceptance. Your auditor will ask about this.
Q5: "How Do We Prevent This from Happening Again?"
You need controls at multiple layers.
At dependency selection: Create an approved components list. Before adding a new dependency, check if it's actively maintained, its security track record, and more. This aligns with NIST 800-53 Control SA-12.
At build time: Implement dependency scanning in your CI/CD pipeline. Tools like Snyk, Dependabot, or OWASP Dependency-Check should block builds with known vulnerabilities.
At runtime: Use SBOMs to maintain inventory. Tools like Syft or CycloneDX can generate these automatically.
At the vendor level: Your vendor risk assessment process should include their supply chain practices. SOC 2 Control CC9.2 requires assessing third-party risks.
Q6: "Our Build Pipeline Pulls from Public Registries—Is That a Problem?"
Yes, it's a common supply chain attack vector.
Public registries are convenient but risky. Attackers often upload malicious packages with similar names to popular libraries or compromise legitimate maintainer accounts.
A better approach is to run a private registry that mirrors approved public packages. Your builds pull from your registry, not directly from public sources. When you need a new package, security reviews it, and you pull a specific version into your private registry. This aligns with NIST CSF Function "Protect" (PR.DS-6).
Q7: "Who Should Own Supply Chain Security in Our Org?"
This is a shared responsibility.
Security team: Defines policies, runs tooling, reviews high-risk dependencies, manages incident response.
Engineering teams: Implement controls in pipelines, maintain SBOMs, follow the approval process for new dependencies.
Compliance/GRC team: Ensures vendor contracts include security requirements, tracks third-party assessments.
Create a RACI matrix to specify responsibilities, such as "reviewing new dependencies" versus "maintaining scanning infrastructure."
Next Steps
Start with your SBOM situation. If you can't generate one for your main applications today, make it your first project. CycloneDX and SPDX are standard formats—choose one and implement it.
Then audit your dependency approval process. Ensure it's documented and followed. Fix this before investing in more tools.
For comprehensive frameworks, refer to NIST 800-53 Control SA-12 and the NIST CSF supply chain risk management guidance. For practical guidance, consider the OWASP Software Component Verification Standard (SCVS).
The next leak is inevitable. The question is whether you'll spend that day figuring out your exposure or executing a plan you've already tested.
