Best Practices for Managing Software Supply Chains

🚨In the AI era, software moves at machine speed. So do supply chain attacks. The npm axios compromise, the enormously popular JavaScript http client with over 300 million weekly downloads, is a sharp reminder of what has changed. This was not typo-squatting. Not a fake package. Not a random dependency buried deep in the graph. This was compromise through a trusted path in the real software supply chain. That is the point leaders need to internalize. The problem is no longer just whether developers write secure code. It is whether the systems, packages, and automation they rely on can still be trusted when software is being assembled, shipped, and updated at machine speed. A short exposure window is all it takes. One compromised package. One CI run. One developer machine. One production workflow. That is enough. A few things every engineering and security leader should be driving right now: 1. Pin exact versions. Stop relying on loose defaults. 2. Enforce lockfiles and deterministic builds in CI/CD. 3. Block install scripts wherever they are not explicitly required. 4. Scan continuously for malicious and tampered dependencies, not just known vulnerabilities. 5. If you were exposed, assume compromise. Isolate, rebuild, and rotate secrets. Do not just patch and move on. Software supply chain security is no longer a developer hygiene issue. It is a leadership issue. It is operational resilience. It is trust. And increasingly, it is board level. The teams that get ahead here will not be the ones reacting fastest after the next incident. They will be the ones that built the controls before it happened. For security and engineering leaders: what is the single control you trust most right now against this class of attack? #SupplyChainSecurity #OpenSourceSecurity #DevSecOps #Cybersecurity #npm Snyk

Powered by Technology, Driven by Regulation: The Evolution of Software Supply Chain Security ! The software supply chain has become a critical area of focus for organizations and governments alike. The increasing use of software and third-party vendors has brought about new risks and vulnerabilities that need to be managed. Over the past year, we've seen a surge in cybersecurity threats, and the software supply chain is a prime target for attackers seeking to exploit vulnerabilities. Regulatory requirements have become an important driver of increased focus on software supply chain security. Governments around the world have introduced new regulations and standards to enforce stronger cybersecurity measures for software supply chains. For example, self-attestation requirements in the United States and Canada require organizations to implement appropriate cybersecurity measures and report on their compliance. The US Food and Drug Administration (FDA) has also introduced new guidelines for the management of cybersecurity risks in medical devices, which includes software supply chain management. In the UK, the Financial Conduct Authority’s (FCA) Cyber and Technology Resilience (CTR) regulatory framework for financial services includes software supply chain management. Meanwhile, technology is playing an increasingly important role in assessing and managing software supply chain risk. DevOps teams are increasingly implementing automation and other measures, such as secure coding practices, testing automation, SBOM, and artifact management, to reduce the risk of vulnerabilities. SBOM provides an understanding of the complete software component supply chain including open source assets. Artifact management provides the ability to maintain a secure software assembly line from code commits to production deployment. Together, the combination of secure coding practices, testing automation, SBOM, artifact management and integrated risk management platforms offer an end-to-end supply chain security during software development, maintenance, and distribution. By adopting these technologies, organizations can proactively identify and mitigate risks in their software supply chain, improve their software development practices and enhance cybersecurity posture. In conclusion, organizations need to assess their own risks and ensure they are compliant with relevant regulations and standards such as self-attestation requirements, FDA requirements, CRA, and NIS 2 directive regulatory requirements in Europe. Also, this requires a culture of ongoing vigilance and investment in appropriate security measures. Self-assessment, periodic third-party audits or automated monitoring can be invaluable to provide an early warning system for potential software supply chain risk. By adopting such a comprehensive approach, organizations can build and maintain more secure software products and associate supply chain environment.

Nobody actually uses the SBOMs they demand from vendors. Most organizations aren't equipped to do anything with them other than checking a box before filling out this week's TPS reports. The worst part is that it creates security busywork on top of not improving actual security. Every hour a vendor's engineering and application security teams spend compiling an SBOM is an hour they aren't spending securing their platform, hardening systems, or addressing the vulnerabilities that matter just to get the stamp of approval and move a deal forward. We absolutely need to care about software supply chain security. But the goal isn't to collect every possible data point; it's to understand and manage actual, exploitable risk. Instead of appsec cosplay, prioritize building strategic partnerships and influence with vendors: 🤔 Understand your critical risks: Focus on what sensitive data the vendor accesses, the level of access they have, and the real-world impact if they were compromised. 🔨 Leverage contracting for real change: Identify the key security controls and practices that genuinely reduce risk for your specific use case. Then, use your leverage during contract negotiation or renewal to get a contractual commitment from the vendor to implement or improve those specific, high-impact areas. This ties their security efforts directly to revenue, giving their security team the budget and prioritization they need. 💬 Prioritize dialogue and proven practices: Engage in direct discussions about their overall security posture and how they address your specific concerns. Support vendors who invest in actionable security, like bug bounty programs, rather than the ones that wave their $49.99 SOC 2 report at you. Remember, only you can prevent security theater!

Ever seen one of those action movies where the villain isn’t who you expect? Cybersecurity works the same way. We spend so much time locking down our vendors (the obvious players) that we forget about the ones behind the curtain: THEIR vendors. That’s where fourth-party risk enters the picture, and it’s one of the big blind spots in cybersecurity. Here are some scenarios: 🎭 A vendor engages with a subcontractor with minimal security controls ☁️ Sensitive data ends up in an unapproved and insecure cloud environment 🧱 Security requirements stop at the first vendor tier It’s like building a fortress only to find out your ally left the side door wide open. In a shared ecosystem, you inherit the security posture of everyone down the chain. It’s not practical to audit the entire scope of downstream contributors. Instead of direct oversight, the responsibility shifts toward rigorous vendor due diligence - ensuring our partners uphold the same security standards we do. Here are some strategies that close the gaps: 1. Map your supply chain. Work with your vendors to identify their critical service providers and create an inventory of your extended supply chain. 2. Perform multi-tiered risk management. Use frameworks like NIST 800-30 to identify and prioritize risks from your external dependencies, including sub-tier suppliers. 3. Push security requirements through your contracts. Consider integrating flow-down clauses to help ensure that entities adhere to the same security standards regardless of their position in the supply chain. These can include mandatory monitoring, data breach notification, and audit rights. 4. Monitor continuously. Point-in-time reviews may not be enough. Explore tools like iTrust (https://hubs.li/Q03NFyqC0) that integrate with cloud platforms and security tools to achieve automated real-time monitoring of third- and fourth-party risks. Fourth-party risk is real and growing. The longer you ignore it, the bigger the gap becomes. How are you getting ahead of it? #CyberSecurity #FourthPartyRisk #SupplyChainSecurity #VendorRisk #TrustNet #RiskManagement #CISO #GRC #InfoSec

Procurement Problem #3: Subcomponent Risk There is a procedural flaw in how we measure supply chain risk. I call it the Ingredient Tracking Problem. Here is the issue: You can have 100 diversified suppliers in your system, yet have 1 single point of failure that takes down your entire company. Procurement manages vendors (Tier 1), but risk lives in the ingredients (Tier 2). We are buying "Black Boxes" without looking at the recipe. Think of this from a physical or a digital perspective. The Physical Trap: You buy laptops from Dell, HP, and Lenovo (hypothetically) to diversify and support business continuity. You think you are diversified but the reality is that all three use the exact same chipset from the same factory in Taiwan. So if that factory has a fire, you don’t lose one supplier; you lose all three. The Digital Trap: You buy SaaS licenses from, say, Asana, Slack, and Trello (this is, again, a hypothetical example). You think your software stack is diversified but the reality is that all three are hosted on AWS US-East-1. If US-East-1 has an outage like we saw last October, your entire operations stack goes dark instantly. The Hilbert Gap: Enterprise systems are architected to track "Who we pay" (The Vendor). They are NOT architected to track "What we consume" (The Dependency). As long as we buy undocumented black boxes, we are flying blind. The Solution? We must not be satisfied with supplier management. Start managing Bills of Material (BOMs) as part of our third party risk efforts. 1. Physical: Enforce an "Enriched ASN" (Advance Ship Notice). Don't just say you shipped 100 widgets; tell me the Lot Number of the battery inside with the EDI 856 document. And have that document linkable to contractual commitments. 2. Digital: Enforce a "Cloud SBOM" (Software Bill of Materials). Don't just sell me the software and basic subprocessors; show me the region where it lives so I can track infrastructure outages back to your performance commitments. To be strategic, Procurement must stop being solely a purchasing department and start being the supplier intelligence agency for the corporation. #Procurement #SupplyChain #RiskManagement #BOM #SBOM #DigitalTransformation #Strategy

CISA, NSA and 19 international partners released a joint guide today on the value that increased software component and supply chain transparency can offer to the global community by implementing software bill of materials (SBOM): "A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity". - This guide informs producers of software, organizations procuring software, and operators of software about the advantages of integrating SBOM generation, analysis, and sharing into security processes and practice. - As modern software increasingly relies on third-party and open-source components, SBOMs offer a foundational step toward understanding and mitigating supply chain vulnerabilities. - This guide emphasizes the importance of SBOMs in identifying risks within software components and encourages their integration into security practices. - It encourages alignment of SBOM technical implementations across countries and sectors to help ensure interoperability, reduce complexity, and enable scalable adoption. #sbom #softwarebillofmaterials #softwaresupplychain #security #cybersupplychainsecurity #supplychainriskmanagement

The initial public draft (ipd) of an important new NIST publication on software supply chain security is now available for public comment. NIST Special Publication (SP) 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines, provides guidance on integrating software supply chain security practices into continuous integration/continuous delivery (CI/CD) pipelines. As the text mentions, threats can arise at any stage of the software development lifecycle. Recent attacks have highlighted the need to secure the entire software supply chain, from design through deployment. This new NIST guide focuses on practical steps organizations can take to build security into their CI/CD pipelines and enhance the integrity of their cloud-native applications. Some key highlights: - Aligns with Executive Order 14028 and NIST's Secure Software Development Framework (SSDF) - Addresses integrating software supply chain security assurance into CI/CD workflows - Provides actionable measures to secure modern software development practices - Helps prepare organizations to address software supply chain risks I encourage anyone involved in software development, especially for cloud-native applications, to review and comment on this draft publication. Strengthening the security of our software supply chains is essential as attacks grow more advanced. Let me know if you have any other thoughts on this topic! #nist #cicd #softwaresupplychainsecurity

Open source is no longer a side detail in how we build software. It is the software supply chain. Most teams depend on dozens or hundreds of third party libraries, yet few have a clear stance on what is acceptable to use, how far behind they can drift, or what signs actually matter when choosing a dependency. As a result, the attack surface keeps growing. #OWASP #SPVS calls this out early. V1.3.3 focuses on establishing a Secure OSS policy during planning, and V2.1.1 asks whether that policy is enforced as part of secure coding practices in the pipeline. These controls exist because supply chain risk cannot be managed after the fact. A simple OSS policy can go a long way when it is explicit. Things like which licenses are acceptable, how often dependencies must be upgraded, how far teams are allowed to drift from current versions such as an N minus 3 rule, and what health signals matter in a third party library. That might include the number of active contributors, how frequently releases happen, and whether security fixes show up quickly when issues are reported. With Software Supply Chain Failures now ranked number three in the OWASP Top 10 for 2025, this is no longer an edge case. It is a shared problem the community has to take seriously. How explicit is your team about the open source risk it is willing to carry? #Cybersecurity #DevSecOps #CICD #SupplyChainSecurity

In a recent session on digital sovereignty, we zoomed in on one of the most urgent issues today: securing the software supply chain. Most enterprises have already moved beyond physical products when it comes down the supply chain. Their real value is now software and that means they’ve also inherited a new kind of risk. 🔍 A few examples that stood out: 1. One company used thousands of open source components in a single application. 2. Many development teams don’t know where all their components come from. 3. Responsibility is often spread across for example frontend teams in India, backend in Sweden, ops in the Netherlands with no clear owner for software quality. In all of this, in recent years, legislation is catching up fast. In the EU, under CRA and DORA, executives can be held personally liable for software that doesn't meet compliance standards. In the US, you can be banned from selling software if it lacks basic supply chain controls. So what does it take to build a secure software supply chain? 📌 Risk-based design 📌 Strict access control 📌 Secure configuration 📌 Vulnerability management 📌 SBOMs (Software Bill of Materials) not just for code, but for all components used Would you like to do this Manually? That is simply impossible. This is why automation and curated tools matter. At SUSE, we help companies do exactly that. Our platform covers everything from infrastructure access controls to curated open source (SUSE Application Collection), dependency mapping (SUSE Observability), and secure deployments (Rancher Prime). And no this isn’t about fear. It’s about building resilience and creating room for innovation without risking your license to operate. #SecureSoftwareSupplyChain #SUSE #SoftwareCompliance #OpenSource #DigitalSovereignty #CyberResilience #SBOM

The software supply chain is under unprecedented pressure. AI agents = more builds, but wow, the malicious attack campaigns on packages in public registries like npm and PyPI are coming fast and furious. It’s a subtle point, but “software supply chain security” isn’t only about security tools per se. The best place to start securing the flow of open source packages into your org is at the artifact layer.  In other words, block unwanted packages before they ever get into your private repositories.  (Your developers DO pull dependencies from private repos, not the public internet, RIGHT?) Security scanners are essential tools, and security research teams are doing super important work right now. The interesting thing is, often they’re seen as part of good CI/CD practices, or as IDE plug-ins. Those are great of course.  But if you’re operating a software factory at any scale, you also want to inject a big dose of security thinking into the artifact layer. After all, that is (or should be!) your system of record for managing and controlling your software supply chain. #DevSecOps #SoftwareSupplyChain