Skip to main content

Three trends shaping software supply chain security today

Écrit par:
blog-feature-open-source-security

22 août 2024

0 minutes de lecture

Building software continues to look like an assembly line, with developers pulling resources from across the web to create applications. Although third-party resources have played an essential role in developing software for many years, the way that development teams use these external components looks different today. Developers incorporate a wider range of third-party resources into their projects, and thanks to AI coding assistants, they can do so at a much faster pace, right in their first-party code. 

As all these changes happen in the software development world, both regulatory bodies and enterprises see the risk in many of these software supply chain practices and continue to push for third-party software regulations. 

Where do these realities leave software development organizations? It means that now, more than ever, companies developing applications must focus on proactive security practices, such as creating testable Software Bills of Materials (SBOMs), shifting code security further left to account for AI-generated code, providing developers actionable tools to help them select secure third-party components, and leveraging business context to prioritize supply chain risk properly. 

To dig into what these types of proactive practices look like, let’s examine three key supply chain trends and how they impact software development:

Growing regulations around SBOMs 

SBOMs are a common thread in many recent compliance requirements and vendor contracts. Public and private sector organizations are upping their SBOM standards as concerns about insecure and malicious components and dependencies grow. Many of these regulations emphasize the importance of regularly updating SBOMs as new third-party resources enter your software ecosystem.

What these regulations mean for today’s teams

Maintaining up-to-date SBOMs will soon make or break your business’s success. As more government and private sector contracts require them, you will need to produce a re-testable SBOM for your own business, ensuring that you can account for any novel threats or changes within your ecosystem over time. SBOMs are also important from a software consumption standpoint, providing software transparency for services that you consume.

AI-generated code

AI coding assistants have quickly become the norm for software development teams today. However, introducing AI-generated first-party code has a few implications for software supply chain security. It means that security teams must tighten foundational code security measures (e.g., static application security testing) and adjust their existing practices and tooling to match the speed at which AI-generated code enters repositories. 

What the rise in AI coding assistants means for teams

AI coding assistants raise the expectations for speed and efficiency across development teams. Developers generally trust AI-generated code more than human-written and hope to move even quicker than before, leaving little room for security practices that drain time and energy. As a result, security teams who got away with old-school code security practices, such as testing first-party code further down the SDLC or requiring developers to switch between tools to test and secure their code, can’t do so anymore. They must consider how to shift further left by offering security tooling within development workflows. 

Evolving threat landscape 

Alongside these factors, the threat landscape has evolved significantly in the past few years, with AI-related threats especially posing new risks to today’s businesses. In fact, the OWASP Machine Learning Security Top Ten project lists AI supply chain attacks as a significant threat to LLMs. By compromising entire machine learning projects, attackers can multiply their efforts and gain access to more assets than if they compromised a static library. 

What the evolving threat landscape means for teams

Teams must identify ways to choose the safest third-party resources from the start. They must then periodically check existing libraries, ensuring none have become compromised. It’s also essential to prioritize third-party vulnerabilities by business criticality. That way, your team can focus on remediating insecurities related to business-critical assets first and then proceed from there. 

Responding to these supply chain security trends

The key to keeping up with these supply chain trends is proactivity. It’s all about anticipating possible risks — whether to your business or the security process itself — and overcoming these possibilities as early as possible. Here are a few questions to get started in switching to a proactive approach:

  • If a bad actor were to break into an application, which areas of business, applications, or libraries would be the worst for them to gain access to? Which ones wouldn’t really matter? These contextual questions can help you understand which business-critical areas should be protected first and which low-risk ones can go to the bottom of your list. Gaining this detailed picture of risk takes a more in-depth approach than simply triaging vulnerabilities by CVSS or reachability.

  • How many context shifts are you asking your development teams to take when they secure first-party code or third-party components? Do they have to leave their coding interface to perform remediation? If so, there’s a good chance that that’s asking too much of them, as they move faster with the help of AI coding assistants. 

  • Which automated guardrails do you have in place to prevent insecure third-party components or licensing issues from entering repositories in the first place? It’s a good idea to curate lists of safe third-party resources for your developers, whether a database of base image recommendations or a way to choose high-quality packages for specific needs, and to build enforcement of your guidelines into the software build and deliver process and pipelines. 

To dive deeper into today’s supply chain security challenges and gain more practical tips, check out our ebook, Securing today’s software supply chains.

Snyk est une plateforme de sécurité des développeurs. S’intégrant directement aux outils, workflows et pipelines de développement, Snyk facilite la détection, la priorisation et la correction des failles de sécurité dans le code, les dépendances, les conteneurs et l’infrastructure en tant que code (IaC). Soutenu par une intelligence applicative et sécuritaire de pointe, Snyk intègre l'expertise de la sécurité au sein des outils de chaque développeur.

Démarrez gratuitementRéservez une démo en ligne

© 2024 Snyk Limited
Enregistré en Angleterre et au Pays de Galles

logo-devseccon