Can We Actually Fix Software Supply Chain Security? 6 AppSec Leaders Debate

The podcast discusses the growing threat of software supply chain attacks, particularly through compromised open-source packages, which are increasingly targeted due to their wide reach and the relative ease of exploiting maintainers with weak security practices. These attacks often aim to steal secrets from developer environments and CI/CD pipelines, with a notable rise in incidents over the past year. The discussion highlights how attackers, including state-sponsored groups like those from North Korea, are leveraging social engineering and automated tools to compromise accounts and distribute malware, driven by high financial incentives and low risk.

A major theme is the imbalance between developer velocity and security, where the culture of prioritizing speed has led to systemic vulnerabilities, especially in CI/CD systems that are often treated as development tools rather than production-grade environments. This is compounded by poor understanding of tooling behaviors, low adoption of available security controls (e.g., npm Trusted Publishing), and technical debt that resists updates. The conversation emphasizes the need for better education, shared responsibility across registries and organizations, and multi-layered security approaches, as no single solution can fully mitigate the evolving threat landscape. AI is highlighted as a double-edged sword, accelerating both development and attacks by lowering the barrier for less skilled threat actors.

Collaboration within the security industry is presented as critical, yet hindered by competition over discovery claims, marketing, and media attention, which can undermine collective progress. Challenges such as delayed removal of malicious packages, backlogs in vulnerability databases, and lack of centralized tracking for supply chain attacks further complicate responses. The discussion advocates for open knowledge sharing, improved coordination through neutral foundations, and sustainable models for providing security resources. Ultimately, the podcast underscores the importance of treating open-source infrastructure with the seriousness it deserves, fostering community-driven solutions, and aligning incentives to make secure practices the path of least resistance.

• What if you treated your CI/CD pipeline as a production system?

  • Move: Audit your GitHub Actions workflows to disable mutable tags, require signed commits, and restrict third-party actions to a pre-approved allowlist using actions/checkout@v4 with persist-credentials: false.
  • Why Now?: Attackers are actively exploiting CI/CD pipelines via OIDC token theft and untrusted action execution - especially in open source - while most developers still treat these systems as low-risk.
  • Expected Upside: Immediate reduction in supply chain attack surface; improved compliance posture; and stronger trust from users and downstream adopters of your software.

• What if you made secure dependency updates the default path for your projects?

  • Move: Replace npm install and npx in all documentation and scripts with npm ci --strict-peer-deps and enforce lockfile-only execution in CI, while enabling npm Trusted Publishing for your packages.
  • Why Now?: Lockfiles are routinely bypassed by common commands, and only 12% of compromised npm publishers use Trusted Publishing - despite available protections.
  • Expected Upside: Reduced risk of dependency confusion and malicious code execution; increased resilience against account takeovers; and alignment with emerging security best practices that registries may soon require.

• What if you published a public malware detection feed for your ecosystem?

  • Move: Set up an automated pipeline that scans your dependencies weekly, logs suspicious packages (e.g., those with obfuscated code or unexpected network calls), and publishes findings in a machine-readable format (e.g., JSON feed on a static site).
  • Why Now?: AI lowers the barrier for attackers to generate novel malware, and registries like NPM still lack real-time, transparent reporting - creating a gap solo developers can fill to build authority and utility.
  • Expected Upside: Establishes you as a trusted signal in your niche; drives traffic and adoption of your tools or services; and creates a reusable asset that compounds security value across the community.

• Audit and harden your CI/CD pipelines by treating them as production-grade systems - disable mutable tags, restrict third-party GitHub Actions, and enforce least-privilege access to secrets.
• Pin or lock all dependencies in your projects to prevent automatic upgrades from compromised or malicious packages in public registries.
• Implement pre-commit or pre-install hooks to scan for malicious code patterns, especially when using npx or npm install, since lock files alone do not prevent runtime execution risks.
• Proactively adopt available security features from registries (e.g., npm Trusted Publishing) even if not compromised - only 12% of affected publishers do, putting you ahead of most peers.
• Shift from velocity-first development to a balanced workflow by introducing mandatory security checks (e.g., automated malware scanning) before merges, reducing supply chain risk without blocking progress.