devopsy.kinsta.cloud

Tag: SBOMs

Software Weaponization Raises DevSecOps Stakes

The threat model that DevSecOps teams have been working from for the last decade was built around accidental vulnerabilities — mistakes that needed to be found and fixed before someone exploited them. That assumption is breaking. Vulnerabilities are increasingly being treated as strategic assets, stockpiled by nation-states and threat actors and held back from disclosure until they’re useful as weapons. That shift changes what “good enough” security looks like across the software delivery lifecycle.

Mike Vizard sits down with Kate Scarcella and Tracy Ragan to dig into what software weaponization actually means in practice for engineering and security teams. Their argument is that the industry has spent years investing in pre-deployment scanning and not nearly enough in knowing what’s actually running in production. The result is sprawling estates of deployed software where teams can’t answer the basic question of which versions, in which configurations, are exposed to a newly disclosed, or quietly hoarded, vulnerability.

They also get into the mechanics of closing that gap. Stronger SBOM practices are the foundation, but only if SBOMs are continuously updated, queryable and tied to the running environment, not parked in a build artifact. From there the conversation moves into automation: using AI-assisted tooling to identify exposed assets fast, prioritize remediation against real exploitability, and push fixes downstream without manual triage at every step.

The other thread is organizational. AI is now both a tool defenders rely on and a source of new risk — data poisoning, model misuse, autonomous agents acting on stale context. Scarcella and Ragan make the case that this is the moment to break down the wall between developers, security teams and data scientists, with shared visibility, shared accountability and a runtime view of the entire software estate as the connective tissue.

May 20, 2026
Tackling the DevSecOps Gap in Software Understanding
When I first read the recent article from CISA titled “Tackling the National Gap in Software Understanding,” I had the same reaction I imagine many of you did: Well, of course this is necessary. Who in their right mind doesn’t want better visibility into the software used in our most mission-critical systems?

But then I thought a bit more. It’s not just necessary—it’s overdue. And not only for national security systems. This gap in software understanding exists across nearly every enterprise and agency in the public and private sector. The real challenge is not recognizing the problem. It’s addressing it early, systemically and sustainably—especially in a DevSecOps context.

Let’s dig into what this really means, why it matters, and where we go from here.

The Software Visibility Gap is a National Risk

The CISA article—and the reports it references from MITRE, NSA, ONCD, and others—highlights a fundamental issue: We don’t know enough about the software running inside our critical infrastructure. We lack the ability to fully understand what’s in our software, how it’s built, and where the risks lie.

This isn’t a new problem. But with the rise of supply chain attacks, component vulnerabilities and ever-expanding software dependencies, the risk is no longer theoretical. It’s existential.

Here’s the kicker: You can’t secure what you don’t understand. You can’t defend what you can’t see.

So yes, we need to close the gap in software understanding—urgently. But the gap isn’t just about national security. It’s a DevSecOps problem at its core.

DevSecOps: Where the Gap Can Actually Be Closed

The big idea in DevSecOps has always been this: shift security left, embed it early and often, and make it everyone’s responsibility.

This makes DevSecOps the perfect context for addressing the software understanding gap. Why? Because the best time to capture visibility into your software’s inner workings isn’t after it’s shipped—it’s while it’s being built.

SBOMs and Supply Chain Security Are Just the Start

Software Bill of Materials (SBOMs) are getting a lot of attention—and rightly so. They provide a machine-readable inventory of every component in a piece of software, down to the library level. SBOMs are a baseline requirement for software visibility, but they’re not the whole story.

What we need is end-to-end traceability—from code to artifact to runtime. That includes:
- Component provenance: Where did this library come from, and who maintains it?
- Build pipelines: What tools and environments were used to compile the software?
- Deployment metadata: When and where was this version deployed, and under what conditions?
This kind of visibility is what lets you “understand” software in the true sense—not just scan it for CVEs.

And the only way to build this visibility in without slowing everything down is to integrate it directly into DevSecOps workflows.

The Role of Policy—and the Promise of Collaboration

I’ll give credit where credit is due: CISA and its federal partners are thinking bigger. They’re not trying to do this in a silo. They’re bringing in multiple agencies—ONCD, NSA, and others—and they’re inviting the cybersecurity and open source communities to the table.

That’s a smart move. Because this isn’t a compliance exercise. It’s a transformation effort.

Too often, the conversation around software security gets stuck on source code access. But as anyone in DevSecOps knows, access to source code alone doesn’t solve the visibility problem. You need insight into artifacts, pipelines, environment variables, configurations, and more. We’re talking about a whole-of-lifecycle approach—not a repo review.

The fact that this is now a coordinated, multi-agency initiative is encouraging. If done right, it could set the standard not only for how the federal government secures software, but how the private sector does too.

Will We See It Through?

And yet… I’ve been around long enough to know how these things go. Big announcement, slick webpage, maybe even a press conference. And then?

Crickets.

We’ve seen this script before. Promising initiatives that fizzle out after leadership changes, priorities shift, or budgets get squeezed. Federal agencies—CISA included—have a revolving door problem. Continuity is hard when your champions keep leaving. You need people who aren’t afraid to speak the truth and do what is right.

So here’s the real question: Will we stick with it? Will the teams behind this initiative have the mandate—and the stamina—to drive this effort forward once the spotlight dims?

Because make no mistake: closing the software understanding gap is not a one-and-done project. It’s a multi-year slog. It requires rewriting procurement policies, updating build systems, retraining teams, and investing in open standards. It’s not glamorous, but it’s vital.

Why It Matters—For DevSecOps and Beyond

If we do see it through, this won’t just be a win for federal cybersecurity. It’ll be a win for the DevSecOps movement.

It will reinforce the idea that visibility, traceability, and accountability are not add-ons—they’re first principles. It will accelerate the adoption of SBOMs, secure build pipelines, artifact attestation, and zero trust architectures.

Most importantly, it will help us build software we can trust. And in today’s world, that’s not just a technical achievement. It’s a national imperative.

Let’s hope we have the will to match the ambition.
August 21, 2025
RunSafe Security Extends Platform Reach to Build More Accurate SBOMs

RunSafe Security this week added an ability to generate a software bill of materials (SBOM) based on the code actually included in an application before it is deployed in a production environment.

The RunSafe Security Platform already enables DevOps teams to safely run code written in languages such as C or C++ by reordering how code is actually executed. That capability prevents cybercriminals from creating, for example, a buffer overflow that exploits a known vulnerability by preventing them from discovering where to inject malicious code.

In addition, the RunSafe Security Platform provides access to monitoring tools that enable DevOps teams to track what components running in memory are being used to build an application. That capability is now being extended to generate an SBOM.

RunSafe Security CTO Shane Fry said that approach creates a more accurate SBOM because unlike other approaches it is not generating an SBOM based on what source code was used or, conversely, trying to analyze application binaries. Both those approaches create SBOMs that are often inaccurate or incomplete, he said.

DevOps teams then have to create a process to manually triage SBOMs using senior application developers that are costly to hire or contract, noted Fry.

In contrast, The RunSafe Security Platform tracks what code is being loaded into an application, either directly from within a continuous integration/continuous delivery (CI/CD) platform or server being used to build software, said Fry. In total, the RunSafe Security Platform keeps track of more than 400 sources of application vulnerabilities to ensure the SBOM created is accurate. They can then opt to safely deploy software with known vulnerabilities by reordering how code is run in memory, or use those insights to better prioritize remediation efforts. noted Fry.

With the rise of more stringent regulations and compliance mandates, the number of DevOps teams now required to provide SBOMs every time an application is deployed or updated has expanded greatly. The challenge is that the SBOMs, rather than providing a precise accounting, represent more of a best guess of what’s been included, said Fry.

It’s not clear to what degree organizations are relying on SBOMs for anything more than complying with a mandate, however, wherever a new vulnerability is discovered knowing exactly what code is running where becomes crucial. Many DevSecOps teams, for example, in the absence of having any SBOM at all are still looking for where all the vulnerable instances of a Log4j tool for monitoring Java code might still be running, more than a year after the issue was initially discovered.

In theory, of course, many organizations are moving to convert unsafe code into another language such as Rust, but those efforts will take many years to complete. In the meantime, when it turns out that the SBOM provided is incomplete or inaccurate there will be an inevitable backlash. Most mandates require an SBOM but don’t have any specific accuracy requirements. It’s largely up to each organization to determine to what degree to comply with the letter versus the spirit of the mandate.

Ultimately, however, there will come a time when a DevOps team that created an SBOM will be called to account for its veracity when the next application security crisis inevitably ensues.

December 19, 2024
Survey Surfaces Software Supply Chain Security Gains

A survey of 106 leaders and practitioners involved in software supply chain security finds more than three-quarters of respondents (76%) work for organizations that have made software supply chain security a significant or top (24%) priority.

Conducted by Anchore, a provider of a software composition analysis (SCA) tool, the survey also finds that 59% of respondents are part of a cross-functional or dedicated team focused on software supply chain security.

Verifying the security of third-party software (46%), the security of open-source software (42%) and the security of the development toolchain (34%) are the top three challenges organizations are encountering. The top priorities are to reduce open-source risk (31%), automate scans across the software development lifecycle (26%), and improve the security of the DevOps toolchain (17%).

Overall, 40% of respondents report their software supply chain has been attacked in the past 12 months, with 21% experiencing a significant impact. Just under a quarter (24%) discovered multiple attacks.

On the plus side, nearly half (49%) are now creating software bills of materials (SBOMs), with 78% planning to increase their usage in the next 18 months. Under half of respondents follow best practices like creating SBOMs for software they develop (49%) or open source software they use (45%) or request from vendors (41%).

Only 10% of respondents currently have a strategy for using the Vulnerability Exploitability Exchange (VEX) format, while 12% consume VEX docs and 8% produce them. One-quarter of respondents expect to adopt VEX in the next six months, and another 15-20% plan to adopt it within 18 months.

Additionally, only 21% of respondents have full visibility of the open-source software components their organization uses, the survey finds.

Josh Bressers, vice president of security for Anchore, said that while there is much work still to be done increased usage of SBOMs suggests that a lot of progress in terms of adopting best DevSecOps practices is being made. Much of that progress is being driven by compliance requirements that are becoming more stringent, he added.

The survey finds on average organizations now comply with 4.9 regulations and standards and well over a third (35%) are making a significant effort to comply with government regulations and standards.

In the long term, a majority of respondents are concerned about the impact artificial intelligence (AI) will have on software supply chain security. The biggest concerns are with code tested with AI (35%) and code generated with AI (32%) or with Copilots (27%).

In general, investment in DevSecOps continues to increase. A separate Techstong Research survey finds that while less than half (47%) of respondents work for organizations that regularly employ best DevSecOps practices, a full 59% of respondents said they are also making further investments in application security, with 19% describing their investment level as high. At the same time, 64% of respondents are investing in a code scanning tool, with 24% describing those investments as high, as well.

As a result, it’s now more a question of when and to what degree the security of software supply chains is about to improve.

November 7, 2024
Survey Surfaces Lots of Software Supply Chain Insecurity

A global survey of 900 application security professionals finds nearly two-thirds work for organizations that have had their software supply chains compromised in the past two years, with 18% being victimized in the last year.

Conducted by Checkmarx, a provider of application security testing tools, the survey also finds that 100% of respondents are aware of a breach of their software supply chain that occurred at some point in the past.

Not surprisingly, the survey finds three-quarters of respondents (75%) are now either very concerned (39%) or concerned (36%) about the security of their software supply chain.

Additionally, well over half (57%) said software supply chain security is a top or significant area of focus, with 54% planning to use or investigate some type of solution. However, only 7% have acquired and implemented a tool or platform to specifically secure their software supply chains, the survey finds.

On the plus side, half (50%) are now requesting software bill of materials (SBOMs) from entities that provide their organization with software, but fewer than half (47%) said their organization can effectively operationalize SBOMs, the survey finds.

Renny Shen, vice president of portfolio marketing for Checkmarx, said the challenge is the scope of the effort required to secure software supply chains is significant. In addition to SBOMs and deploying tooling to discover vulnerabilities and malware, DevSecOps teams also need to, for example, embrace zero-trust initiatives to secure access to their software supply chain.

There is no single tool or platform that enables DevSecOps teams to achieve that goal, he added.

In general, securing software remains challenging because even if a vulnerability is discovered a DevSecOps team may not be able to fix it, noted Shen. For example, well over half (56%) of the applications deployed are based on open-source code packages that organizations are dependent on external maintainers to update.

On the plus side, however, software supply chain security has become a C-level discussion, said Shen. The challenge is that many organizations have yet to define a set of key performance indicators (KPIs) that enable them to ensure best DevSecOps practices are being adopted. Right now, there is not enough emphasis on application security so developers will continue to focus most of their time and effort on writing new code rather than fixing existing code, he noted.

Unfortunately, most organizations don’t prioritize application security so until there is a fundamental shift in incentives it’s not likely developers will spend more time remediating vulnerabilities. There has been an effort to shift more responsibility for security further left toward developers, which has been met with mixed success. Developers generally have access to more tools but unless those tools are surfacing issues as developers write code it’s not likely they will have a meaningful impact on improving the overall state of application security.

Hopefully, the rise of generative artificial intelligence (AI) will soon make it simpler to find and remediate vulnerabilities by, for example, automatically creating the required patch. In the meantime, however, securing software supply chains requires a level of vigilance that despite best intentions remains difficult to achieve and maintain.

July 3, 2024
CISA, NSA Issue Supply Chain Security Guidance Report

The National Security Agency (NSA), Office of the Director of National Intelligence (ODNI) and Cybersecurity and Infrastructure Security Agency (CISA) have issued guidance to assist software developers and suppliers to shore up software integrity and security across various stages of the software lifecycle.

The report, Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption, was developed by the Enduring Security Framework (ESF) Software Supply Chain Working Group.

The report offered recommended practices as a framework for assessing and improving security practices concerning software development, release, updates, vulnerability notifications and mitigation.

The guidance also addressed the escalating cybersecurity threats targeting software supply chains, which have exposed vulnerabilities susceptible to exploitation by state adversaries.

It highlighted potential risks such as design flaws, integration of vulnerable third-party components, infiltration of supplier networks with malicious code and malware injections in deployed software.

To combat these threats, the report underscored industry best practices, emphasizing open source software management and software bills of materials (SBOM).

Specific areas covered include SBOM consumption, life cycle, risk assessment and operational implementation, ultimately promoting enhanced transparency and risk management throughout software life cycles for organizations.

Alex Kreilein, vice president of product security at Qualys, said while the concept of an SBOM is not new, organizations now have concrete and foundationally important guidance on how to make operational use of SBOMs while developing, managing or consuming them.

“The guidance supplied by the Enduring Security Framework reduces the complexity of SBOM management, making it accessible to everyone for the first time,” he noted. “SBOMs are part of a healthy software ecosystem, but are by no means the only factor.”

He explained that while the SBOM is an effective output, it cannot be trustworthy if the system that created it cannot validate the provenance of the product.

“It’s critical for organizations to understand the whole supply chain from code through pipeline to production,” Kreilein said.

He added that this is why The Linux Foundation and Google started the Supply-chain Levels for Software Artifacts, or SLSA framework, as a practical set of methods to action NIST recommendations in the Secure Software Development Framework (SSDF).

John Gallagher, vice president of Viakoo Labs at Viakoo, called the report a “major step forward” in providing an overall framework and transparency for how SBOMs are constructed, maintained and used.

“One of the key ways this helps relieve concerns over software supply chain security is by providing clear guidance on the risk scoring mechanisms,” he said.

This augments other software supply chain efforts (though it doesn’t replace them) in areas like the use of SBOMs in SaaS environments or version control mechanisms for SBOMs.

He noted two significant points on implementation that come out of this framework; first is that it gives guidance to departments like procurement as to what they should be requiring from their vendors, and second it gives a framework for solution providers to base their consumption and generation of SBOM and Vulnerability-Exploitability eXchange (VEX) data on.

“While this document does not address the methods of remediation, it does help to more quickly identify software supply chain vulnerabilities so that they can be addressed early on and ideally before the widespread use of that vulnerable code,” Gallagher said.

He noted that the more vulnerabilities that are caught early or before they are broadly used the later stage of remediation is either much easier or not needed.

Anthony Tam, manager of security engineering at Tigera, said when vulnerabilities have been identified, it is important to prioritize them based on severity and potential impact.

“This allows organizations to allocate their resources more effectively and focus on the most critical vulnerabilities first,” he explained.

Prioritization can be done by using a risk-based approach, considering factors such as the likelihood and potential impact of a vulnerability being exploited.

“By prioritizing vulnerabilities, organizations can ensure that they are addressing the most critical security risks first and reducing the overall risk to their software system,” Tam noted.

November 21, 2023
Technical Debt: Don’t Buy Buzzwords

It is absolutely true that the only constant in IT is change. No sooner do a mass of us get the ‘next big new shiny thing’ implemented than people start telling us how much we need the next ‘next big new shiny thing.’ Often, that next big new shiny thing is actually helpful, and we feel (sooner or later) compelled to implement it. Sometimes, the next big new shiny thing is not very useful at all, and yet far too many of us implement it anyway.

Not naming names here, but you’ve all got technical debt that I would classify as “bling” or “keeping up with the competition” functionality. It’s there; you’re paying for it and/or to maintain it, and yet it provides little value. Sometimes, you’re even forbidden from removing it because it is some exec’s pet project or some corner department is actually using it. You’d just have to replace this version of the next big new shiny thing with a different version.

And I’m here to tell you: Stop. When considering new technology, the very first thing to do is build a list of the problems you are trying to solve and then describe scenarios where those problems crop up. Then compare the next big new shiny thing–be it features in an existing product or a new space/product completely–to how it solves real needs. People are the absolute worst about this with open source. “It’s free, so let’s try it out.” It. Is. Never. Free. And it is a rare team that tries it out and then removes it if it doesn’t work. Most of the time, they’re off to the next project too quickly to do that level of cleanup.

SBOMs and SCA are ‘next big new shiny things’ of the recent past that actually help you clean up test/pilot garbage from the latest bout of next big new shiny things. So are containers since you can spin them up, play with the toys and then take them down. I am surprised at the number of teams out there who do not do this, but that’s changing pretty quickly. Use them; it’ll save a ton of cleanup time and a lot of technical debt.

But most importantly, only buy what you absolutely need. We’ve been dropping an ever-increasing number of tools into the development environment for a decade, and those tools do not (yet) maintain themselves. There is infrastructure cost, possibly licensing cost and staff time. Don’t waste it; focus on what is literally most important.

And that might mean putting your foot down. We in IT have been loathe to do that since Agile started, but telling a C-level that they don’t need an AI to create new drink recipes (or whatever the current generative AI boardroom craze is) is in the best interests of the company. Focus on systems that help do the work or that protect what does do the work.

You’re still rocking it, so if rocking the boat a bit in the process causes problems, you might just be at the wrong company or in the wrong role. Achieve, but achieve meaningful results.

September 27, 2023
The Role of SBOMs in Software Supply Chain Security

The software supply chain has become increasingly complex and dynamic with the rise of cloud computing, open source software and third-party software components and APIs. Widespread damage can occur if third-party APIs, cloud services, SDKs and open source software have security flaws. As a result, software supply chain security has emerged as a critical concern for organizations across industries. Supply chain attacks have become more frequent, sophisticated and devastating, as evidenced by high-profile incidents such as SUNBURST, Kaseya and Apache Log4j.

To address the growing challenge of software supply chain security, organizations have turned to leveraging software bills of materials (SBOMs). SBOMs are a standardized inventory of software components used in a particular product or system, including their versions, dependencies and sources. SBOMs provide transparency and visibility into the software supply chain. They can be an effective approach for identifying and mitigating security risks, compliance issues and operational challenges – assuming organizations have the right tools to fully benefit from SBOMs, including runtime discovery, in place.

SBOMs are not a new concept, but their adoption has accelerated in recent years due to a number of important factors, including the following.

First, regulatory agencies, such as the U.S. National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Agency (CISA), have been advocating for SBOMs as a best practice for software supply chain security. NIST has released a draft guidance document on SBOMs, and CISA has mandated SBOMs for federal contractors and subcontractors.

Second, industry initiatives, such as the Open Source Security Foundation (OpenSSF) and the Software Assurance Forum for Excellence in Code (SAFECode), have promoted SBOMs as a key element of software security. OpenSSF has launched a working group on SBOMs and published the Open Source Software Security Mobilization Plan to improve the resiliency and security of open source software (OSS), including guidelines for SBOM management; SAFECode published a whitepaper on SBOMs.

Third, supply chain attacks have highlighted the need for SBOMs as a proactive and preventive measure. SBOMs can help organizations detect and respond to vulnerabilities, malicious code and unauthorized changes in the software supply chain. SBOMs can also support incident response and recovery efforts by providing accurate and comprehensive information about the affected software components.

Fourth, customer demands and market pressures have influenced the adoption of SBOMs. Customers are increasingly aware of software supply chain risks and are asking for SBOMs as part of their procurement and evaluation processes. Some industries, such as health care and automotive, have mandated SBOMs for safety and liability reasons. SBOMs can also enhance brand reputation, customer trust and competitive advantage for software vendors.

Fifth, technological advancements have facilitated the creation and consumption of SBOMs. The emergence of open standards, such as CycloneDX and SPDX, has enabled interoperability and integration of SBOMs across different tools and platforms. The development of automated tools, such as software composition analysis (SCA) and vulnerability scanners, has enabled the generation and validation of SBOMs in a timely and accurate manner. The integration of SBOMs with other security measures, such as identity and access management (IAM) and security information and event management (SIEM), has enabled an effective view of software supply chain security.

However, SBOMs are not a silver bullet for software supply chain security. They are only as good as the data they contain, and the quality of data can vary depending on the source and the method of collection, particularly around the application software stack of APIs, cloud services and SDKs. SBOM inventory is constantly changing, and being able to leverage their up-to-date data requires more than a snapshot from traditional source code static analysis approaches, but rather continuous runtime analysis and dynamic inventory.

For example, common vendor management and software composition analysis (SCA) approaches often lack source code access for mobile, web, cloud and commercial-off-the-shelf (COTS) software, as well as third-party API services.

For a more effective approach, organizations can benefit from a full-stack attack surface management (ASM) software supply chain solution that delivers continuous third-party application asset discovery and dynamic tracking of third-party vendors. These newer approaches automatically categorize assets under known vendors, allow customers to add additional new vendors, curate individual assets under any vendor, and alert on increases in policy violations and high embed rates of third-party vendors within key applications. These automated capabilities allow vendor management teams to remedy supply chain security problems more quickly and easily and much more accurately than older approaches.

It is important to note that SBOMs also require collaboration and communication among multiple stakeholders, including software vendors, suppliers, customers and regulators. They may also pose some privacy and intellectual property concerns since they can reveal information about the software components and their relationships.

Overall, organizations need to adopt a comprehensive and risk-based approach to software supply chain security, of which SBOMs and tools to best leverage their information are an important component. Organizations should establish policies and procedures for SBOM creation, management and sharing, as well as for validation and verification. Organizations should also integrate SBOMs with other security measures and practices, such as threat modeling, penetration testing and code review to best ensure the security of their software supply chains.

May 23, 2023
A DevOps Guide to the Language of DevSecOps
Security is increasingly important for DevOps due to the growing complexity of applications and the accelerated pace of development. As organizations adopt DevOps practices, they face new challenges in securing applications and infrastructure:
- Increased complexity and automated processes: With automation at the core of DevOps, processes and applications are more intricate. This can introduce vulnerabilities if not carefully managed and secured, as they often involve multiple systems and components that need to be protected.
- Reliance on code repositories: DevOps teams depend heavily on code repositories for version control and collaboration. However, these repositories can be targets for attackers seeking to inject malicious code or steal sensitive information, making it crucial to secure access and maintain good security practices.
- Larger attack surface: The DevOps pipeline consists of numerous tools and components, including source code management, build systems, testing frameworks and deployment tools. Each of these elements presents potential attack surfaces and needs to be secured to protect the overall application.
- High-velocity development: The rapid pace of development in a DevOps environment can sometimes lead to security being overlooked or deprioritized. As new features are pushed out quickly, there may be less time for thorough security reviews.
- Tooling limitations: While many DevOps tools come with built-in security features, these may not be sufficient to protect against all threats. Relying solely on these features could create a false sense of security, leaving organizations exposed to potential attacks.
What is DevSecOps?

DevSecOps enables teams to shift security left and integrate it continuously across the entire SDLC rather than as an afterthought. It is a cultural shift even for DevOps teams, as it requires all members to adopt a security mindset that ensures software is not only released fast and at the highest possible quality but also includes all security measures and checks from the design phase.

It typically involves adopting secure coding practices and implementing application security testing tools that help design, test, verify, release, and update secure software in a secure manner. It requires ensuring that not only the software itself is secure, but also the development environment and the entire supply chain is secure. As a result, DevSecOps rely on a high level of automation tools to reduce manual work to a minimum.

DevOps Guide to Security Acronyms

All DevOps pros need to become familiar with key security concepts. Here are a few concepts that will help you communicate better with security teams in your organization and one day become a DevSecOps geek yourself.

1. SBOM—Software Bill of Materials

A software bill of materials (SBOM) comprises all components and software dependencies in the application’s build and delivery. It provides visibility into all the different components and licensing included in a piece of software to help discover potential vulnerabilities and licensing risks.

2. DAST – Dynamic Application Security Testing

DAST involves analyzing applications or services while they are running to identify security vulnerabilities. This technique typically simulates attacks to learn how a malicious actor might exploit the user or application interface. Teams use DAST tools to detect complex vulnerabilities caused by specific functionality that a static analysis tool cannot find when analyzing the source code.

3. SCA – Software Composition Analysis

SCA tools identify security vulnerabilities in third-party components and dependencies. Teams can integrate SCA to run across the entire development pipeline to build an open source dependency tree for the application and map these components against a database of known vulnerabilities. The tool generates reports on vulnerable open source components found in the application that require fixes or patches.

4. SAST – Static Application Security Testing

SAST tools analyze the source code of applications, services, and microservices, trying to identify potential vulnerabilities caused due to insecure coding practices. Teams can integrate SAST tools into their continuous pipeline, setting them up to automatically search the source code for coding patterns and insecure objects or functions that can result in security vulnerabilities. SAST is commonly used to identify vulnerabilities during the coding phase or when pushing code to a testing environment.

5. IAST—Interactive Application Security Testing

IAST involves analyzing the source code for vulnerabilities while the application is running. The main advantage of IAST is that this method reports vulnerabilities in real-time and does not add additional time to the CI/CD pipeline. It works from within the application, distinguishing it from both SAST and DAST techniques that work externally. IAST does not scan the entire codebase. Instead, it checks only the aspect exercised during the functional test.

6. RASP—Runtime Application Self-Protection

RASP is a defensive technique built into the tested application to detect and respond to attacks as they occur. It is typically implemented using third-party tools embedded within the application to monitor incoming requests and the application’s behavior, such as packages, plug-ins or libraries. These components inspect requests and the application’s behavior to block and protect against threats.

7. OWASP—Open Web Application Security Project

OWASP is a nonprofit devoted to helping improve software security by offering free resources and tools. This organization consists of a large community of volunteers who help propose, build and manage projects and educational materials that support the wider software development and security community.

8. XDR—Extended Detection and Response

XDR solutions collect and correlate deep activity data and detections across various security layers, including endpoints, emails, servers, networks, and cloud workloads, performing automated analysis to help detect threats faster. Teams can use this information to take quicker action during investigations. The main advantage of XDR solutions is that they help break down the security silos that allow stealthy threats to evade detection.

9. XSS—Cross-Site Scripting

XSS is a security vulnerability. It plagues so many web applications that it has yet to be removed from the OWASP Top 10 web vulnerabilities list since it was first included in the 2003 version. XSS vulnerabilities enable threat actors to execute malicious script code in one or multiple users’ browsers. Actors often use XSS to gather sensitive information, such as user session details and personal data.

10. SQLi—SQL Injection

SQLi is a code injection technique that enables threat actors to attack applications. It typically occurs when applications require user input, such as usernames, but receive a malicious SQL statement instead. To launch this attack, actors must locate vulnerable user inputs in the web application, create input content and send it. If the database executes the malicious SQL command, the attacker gains access to the database.

11. CSRF—Cross-Site Request Forgery

CSRF is a common web application attack that exploits the trust between a user and an application to conduct various malicious actions. Threat actors use CSRF to hijack an authenticated session between a user’s browser and an application. Once actors have access to the session, they can use it to execute functionality on that application.

12. SAML—Security Assertion Markup Language

SAML is a standard used to securely share information about identities, authentication, and authorization between various systems. It is typically implemented with the Extensible Markup Language (XML) standard for data sharing and often provides an open framework to implement a federated identity system like single sign-on (SSO).

Conclusion

In today’s chaotic cyber landscape, DevOps teams cannot solely prioritize the fast release of high-quality software. To ensure their software, infrastructure and development environment are protected, DevOps teams must integrate security into the entire SDLC. This endeavor requires adopting a security mindset and utilizing tools that help create an efficient and secure pipeline.

The acronyms discussed in this article include essential security aspects DevOps teams should get familiar with, such as the OWASP organization that provides important guidance on building secure software, tools that help shift security left and common web vulnerabilities. However, teams should branch beyond these practices and tools to create a comprehensive security policy that covers their unique needs and requirement.

Image Source
April 7, 2023
Lineaje Unfurls Platform for Creating and Managing SBOMs

Lineaje this week unfurled a platform for creating and managing the software bills of materials (SBOMs) that are increasingly mandated by enterprise IT organizations and government agencies.

Fresh from raising $7 million in seed funding, Lineaje CEO Javed Hasan said the SBOM360 platform provides a simpler way to manage all the SBOMs that will soon inundate organizations.

The SBOM360 platform makes it possible to use a search engine to discover all the components of an application and all the dependencies that exist within it, including vulnerabilities, and indicators of compromise (IOCs) in seconds, said Hasan. The company then adds fingerprinting technology that enables the platform to attest to the authenticity of the entire software supply chain, he added.

While there is no shortage of tools for creating SBOMs, there are not as many platforms that enable DevOps teams to both create and manage them. In the wake of an executive order issued by the Biden administration requiring federal agencies to have an SBOM for all the software they use, interest in SBOMs to better secure software supply chains has significantly increased. However, very few organizations have a process in place that enables them to operationalize all the SBOMs that might be created.

More challenging still, the pace at which software is being updated has accelerated to the point where many SBOMs are likely to be outdated. The only way to keep pace with that rate of change is to rely on a platform designed from the ground up to dynamically create SBOMs in seconds, noted Hasan.

Finally, IT organizations are now being held more accountable for legacy software often polluted with vulnerabilities that need to be remediated, he added. As such, organizations need a tool that makes it simpler to identify vulnerabilities within the context of an SBOM.

It’s not clear whether greater awareness of the need for SBOMs is translating into concrete action, but the expectation is that more organizations will soon be following the lead of the federal government by requiring them. That shift will naturally bring a lot of additional pressure to bear on DevOps teams. Historically, organizations tended to allow developers to aggregate software components without always checking to see if they are compromised. Cybercriminals are becoming increasingly more adept at injecting malware into software components in the hope that malware will find its way into any number of downstream applications.

Regardless of the approach an organization takes to better secure software supply chains, more rigor is being applied to how software is built and deployed. The days when developers were free to aggregate software components as they saw fit by, for example, relying on open source software downloaded from a repository, are now at an end. The expectation now is the developer will be held accountable for the integrity of all components used within an application as organizations move to implement additional processes to more rigorously review code before it is deployed in a production environment.

February 9, 2023