Kubernetes 1.33 was released today.
Software engineers are currently caught between a rock and a hard place.
The rock? They're under record pressure to produce and release new software.
The hard place? They're increasingly expected to account for the safety, security and provenance of every single software asset they use in those builds. That's demonstrated in the rise of the Software Bill of Materials (SBOM).
These two clashing requirements are a source of great anxiety for software engineers, who are now forced to learn a new discipline while being simultaneously expected to do their existing jobs faster.
The Rise of the SBOM
SBOMs have risen due to a growing need for transparency in the software development process.
It's easy to understand how this has come about. The supply chain clearly needs greater transparency and continues to be the source of much insecurity and technology failure. In August 2024, for example, a faulty update to the widely used Zoom software caused outages for millions of customers, paralyzing businesses and education institutions alike. In January 2025, another faulty update caused outages for many organizational Slack users who found they couldn't use one of their most fundamental business communication tools.
As the world becomes more tightly locked in the digital realm, we become ever more vulnerable to risks in the supply chain. Furthermore, there's a growing body of regulation — including a variety of presidential Executive Orders and National Institute of Standards and Technologies (NIST) guidelines — which compel organizations to account for those risks or face compliance penalties.
All of this has led to the rise of the SBOM, in which the components and dependencies of a piece of software are cataloged for the inspection of clients, channel partners, regulators and subsequent links in the supply chain.
While this is a broadly positive development, it is also a cause of great worry for software engineers who are now being forced to account for every single component used within their releases.
"That's Not My Job"
It's important to note that software engineers are not security professionals, but in some important ways, they are now being asked to be.
Software engineers pick and choose from various third-party and open source components and libraries. They do so — for the most part — with little analysis of the security of those components. Those components can be — or become — vulnerable in a whole variety of ways: Once-reliable code repositories can become outdated or vulnerable, zero days can emerge in trusted libraries, and malicious actors can — and often do — infect the supply chain. On top of that, risk profiles can change overnight, making what was a well considered design choice into a vulnerable one almost overnight.
Software engineers never before had to consider these things, and yet the arrival of the SBOM is making them do so like never before. Customers can now scrutinize their releases, and then potentially reject or send them back for fixing — resulting in even more work on short notice and piling on pressure. Even if the risk profile of a particular component changes between the creation of an SBOM and a customer reviewing it, then the release might be rejected.
This is understandably the cause of much frustration for software engineers who are often already under great pressure. The structural conditions that are now bearing down on software engineers can't be dismissed, but they can be accommodated while taking the stress off already-stressed development teams.
Assisting Engineers Around the Learning Curve
Principally, software dev teams need to know how the build decisions they make become vulnerable, so they can design with security in mind, and create reliable SBOMs.
That will mean integrating security insight into the development pipelines that software engineers work within. For example, being able to change and track dependencies so that the dev team will immediately know whether a particular choice will create software failures or security vulnerabilities later down the line. It will also let them know whether the components and libraries they once-thought reliable are now vulnerable or outdated.
Threat detection scans can add another layer of insight, offering a look at the source code level and providing a risk profile of both a release's behavior and its dependencies. It's this kind of insight during development that will allow software engineers to climb that steep learning curve that the SBOM presents. It will also furnish those development teams with proof points that they designed a given release securely, even if those releases have since become outdated or vulnerable. That ability to track and catalog changes in the risk profile of components and dependencies must also extend past dates of release, so that engineers can be involved in the continuing security of their creations.
SBOMs are here to stay and rightly so. We've reached a global level of digital complexity in which we have to know what kinds of components and technologies we're dealing with at every stage of the supply chain. A lot of that added responsibility is now falling to software engineers and they need ways to ease the mounting pressure. The SBOM shouldn't be resisted, but it can be accommodated and building SBOM creation tools into the development process can ease that pressure and help engineers adapt to the new reality.
Industry News
Docker announced a major expansion of its AI initiative with the upcoming Docker MCP Catalog and Docker MCP Toolkit.
Perforce Software announced the release of its latest platform update for Puppet Enterprise Advanced, designed to streamline DevSecOps practices and fortify enterprise security postures.
Azul announced JVM Inventory, a new feature of Azul Intelligence Cloud designed to address the complexity and risk of migrating off Oracle Java.
LaunchDarkly announced the acquisition of Highlight, a powerful, open source, full-stack application monitoring platform known for its error monitoring, logging, distributed tracing and session replay capabilities.
O’Reilly announced AI Codecon—a groundbreaking virtual conference series dedicated to exploring the rapidly evolving world of AI-assisted software development.
Veracode unveiled new capabilities offering proactive risk mitigation and automated security at enterprise scale.
Snyk launched Snyk API & Web, delivering a dynamic application security testing (DAST) solution designed to meet the growing demands of modern and increasingly AI-powered software development.
Check Point® Software Technologies Ltd. announced that it has ranked as a Leader and the only Outperformer for its Check Point Quantum Security Solutions in GigaOm’s latest Radar for Enterprise Firewall report.
Postman announced new releases designed to help organizations build APIs faster, more securely, and with less friction.
SnapLogic announced AgentCreator 3.0, an evolution in agentic AI technology that eliminates the complexity of enterprise AI adoption.
GitLab announced the general availability of GitLab Duo with Amazon Q.
Perforce Software and Liquibase announced a strategic partnership to enhance secure and compliant database change management for DevOps teams.
Spacelift announced the launch of Saturnhead AI — an enterprise-grade AI assistant that slashes DevOps troubleshooting time by transforming complex infrastructure logs into clear, actionable explanations.
CodeSecure and FOSSA announced a strategic partnership and native product integration that enables organizations to eliminate security blindspots associated with both third party and open source code.