devopsy.kinsta.cloud

Tag: vulnerabilities

  • Mobb Launches Community Edition of Automated Remediation Tool

    Mobb Launches Community Edition of Automated Remediation Tool

    Mobb today made available a free community edition of a namesake tool that creates fixes to open source vulnerabilities. The fixes are based on the results of code scanning by a static application security testing (SAST) tool.

    Fresh from raising $5.4 million in seed funding, Mobb CEO Eitan Worcel said the company developed a tool that creates validated patches based on the scan results of third-party SAST tools from Checkmarx, GitHub and Snyk. Initially, the tool is aimed at Java vulnerabilities.

    Worcel said that most vulnerabilities can be traced back to eight types of mistakes that developers routinely make. The company created a pattern for those common mistakes, along with patterns to fix them, called Mobb rules. That ability enables Mobb to accurately produce a code fix that both remediates the vulnerability and adheres to the correctness of the language to eliminate code defects. Mobb then makes available a patch to address those issues in a way that can be readily downloaded and applied by developers. Mobb does not automatically apply those fixes because most developers prefer to review them first, noted Worcel.

    The Mobb approach eliminates the need for IT teams to sort through SAST scans themselves, which can result in the discovery of thousands of vulnerabilities that might theoretically need to be fixed. Each vulnerability, at minimum, is going to require 30 minutes to fix, so the Mobb platform provides a better return on investment and reduces patch backlogs, added Worcel.

    For decades, application development teams have been attempting to find a way to remediate vulnerabilities as quickly as possible. With increased focus on adopting DevSecOps best practices to address those vulnerabilities, more organizations are now reviewing which types of vulnerabilities should have a higher remediation priority.

    Historically, one of the reasons for the wide divide between application development teams and cybersecurity professionals is that many of the vulnerabilities being discovered don’t actually impact applications running in production environments. Development teams then find themselves wasting time investigating vulnerabilities and, when they do determine a vulnerability is an issue, spending time developing a patch. The Mobb tool addresses that later issue by automatically creating the necessary patch, said Worcel.

    Many organizations just allocate junior developers to the task of remediating vulnerabilities, which Worcel noted frees up more experienced developers to focus on writing additional business logic.

    There will, of course, be vulnerabilities that the Mobb tool will not be able to address simply because there may not be enough affected applications to warrant pre-building a patch. Even with the most robust set of rules, it is improbable that an automated tool can, with 100% certainty, safely fix every issue. However, given the number of routine vulnerabilities present in applications, such as SQL injections, there’s plenty of opportunity to improve developer productivity by relying on patches that have already been developed.

    One way or another, the process by which patches are prioritized, developed and then applied has long been a source of DevOps frustration. Anything that streamlines that process will go a long way toward improving the overall state of application security at a time when cybercriminals are becoming more adept at exploiting vulnerabilities wherever they may be found.

  • Benefits and Challenges of DevSecOps for Business

    Benefits and Challenges of DevSecOps for Business

    Almost every day, there is a new tactic or technique discovered that hackers can use to disrupt a company’s systems, obtain critical data and information or steal money. Often attackers look to exploit vulnerabilities in code to carry out their attacks. Ironically, it’s usually a small piece of code that helps a business perform very simple tasks that can become the root of this serious issue (e.g., logging, report service and glue for application). In fact, it only takes one exploitation, vulnerability or human error to cause a data breach that, on average, costs $4.35 million. Some experts projected that by 2025, these breaches could cost a total of $10.5 trillion. Therefore, CEOs and other corporate executives should reflect on these incidents to ask themselves what would happen if someone entered their systems to exploit code and what it could mean for their company.

    The Problems That a Business Faces

    In traditional development practices, security serves a ‘gating’ function. Security checks are performed prior to releasing an application to production and, if issues are found, security stops rollouts. This can have disastrous ramifications.

    The unknown can be frightening, but that’s where DevSecOps can help. DevSecOps incorporates security into every step of the software development life cycle (SDLC) from requirements to architecture and design, coding, testing, release and deployment. By automating and integrating security practices into the software development life cycle, development teams can react to vulnerabilities sooner, automate security checks and proceed into production with a more reliable and secure product.

    The benefit is felt when a tactical vulnerability is discovered and the DevSecOps practice is already in place to ensure that it can be remediated with limited impact on the business.

    The Business Benefits of DevSecOps and Best Practices

    Streamlining the SDLC and including security checks (often automated) in the process early in the development cycle can identify a problem before it can negatively affect the bottom line of the development effort and the business. Having a vulnerability remediated early in the development cycle is an order of magnitude less expensive than one discovered just prior to production.

    DevSecOps works best in an organization where Agile practices have been adopted to swiftly enable continuous integration, deployment and scalability. The road to streamlining and automating these practices can be long, but when effectively applied, DevSecOps best practices reduce costs for the company and accelerates time to market.

    For DevSecOps to be effective, security must have a seat at the table when requirements are gathered and architectures are planned. This integration of work practices ensures that risks are identified early and can be mitigated well before an application is launched in production.

    Using that same connection with operations, security procedures should be established to feed new vulnerability discoveries into the pipeline for remediation. However, implementing DevSecOps isn’t a magic fix and it won’t happen immediately. But why can it be so hard to implement?

    Overcoming the Challenges of DevSecOps

    There are many difficulties when it comes to implementing DevSecOps. Here are two of them:

    1. Cultural Shift:
    Leading with a DevSecOps approach requires a huge culture shift within the organization that challenges the way many departments operate today. Many employees might find it difficult to drastically change what they’ve been doing for years. Another roadblock is the belief that better protection slows down processes and restricts innovation. Quick code production is a goal for developers who want to meet the demands of businesses, while on the other hand, security teams are focused on making sure the code is secure.

    Thorough training for both security and development experts will help overcome some cultural obstacles but integrating the goals and objectives of both teams will push the adoption of DevSecOps practices. Organizations will begin to see security align to faster time and flexibility of solutions while developers will begin to adopt a security-first mindset.

    2. Complex Tool Integrations:
    Most DevOps toolchains are produced by different vendors. Teams select source code management, continuous integration/delivery (CI/CD), build tools, binary libraries, code review and problem monitoring solutions based on their unique needs. Adding security tools into that pipeline can create a challenge for ensuring the best results for both teams.

    Security analysis in the development pipeline is done with tools that perform software composition analysis (SCA), static application security testing (SAST), and some form of dynamic testing. Integration into the pipeline of these tools is significant and creates difficulties for developers. The developer must know the intent of the scan and what to do with the problems they uncover. It is important that developers have an accurate understanding of where the problem arose and what the issues mean. However, combining and comparing the results and data of many vendors’ resources might be challenging.

    The best course of action would be to consolidate your solutions. This will not only make things simpler for the developer and the organization, but it may also reveal threats that the organization wasn’t previously aware of.

    Overcoming these obstacles is not an easy task, but it is possible. Once a DevSecOps approach is accepted and fully implemented across your company, you can expect code to be developed with fewer bugs and security risks. The cost of deploying code will also eventually decrease, and at a pace that helps the organization maximize its return on investment. Overall, systems created within this process will be significantly more flexible and capable of adjusting to modern-day threats and change in the midst of a digital transformation.

  • Massive Number of Transitive Dependencies Traced to Open Source Code

    Massive Number of Transitive Dependencies Traced to Open Source Code

    An analysis of nearly 2,000 software packages published by Endor Labs found 95% of all application vulnerabilities can be traced back to a transitive dependency created when a developer used an open source component.

    The study, conducted by the Station 9 research arm of Endor Labs, a provider of a platform for identifying software dependencies, concluded there’s still a 32% chance those software packages would have known vulnerabilities even after components are upgraded to the latest version.

    Endor Labs CEO Varun Badhwar said vulnerabilities often remain because the last update made to one of those software components may have been made several years ago even though there are existing known vulnerabilities that affect it. Development teams can’t assume the latest version of a software component is secure, he added.

    In general, functional dependencies are created whenever developers download a third-party component, he noted. The most important thing for any software development team to determine when assessing actual risk levels created by those dependences is determining how accessible any given vulnerability is to an attacker regardless of its severity score, noted Badhwar.

    In the wake of a series of high-profile breaches, there has been an increased focus on software supply chains. The challenge is most developers don’t have a lot of cybersecurity expertise. They often create patches for applications based on a list of potential vulnerabilities surfaced by cybersecurity teams. The issue, of course, is that just because there is a vulnerability it does not immediately follow that the affected software component can be externally accessed.

    Endor Labs is making a case for a graph-based platform that identifies dependencies between the software components that make up an application environment. That approach makes it simpler to prioritize remediation efforts based on the impact a vulnerability might actually have and narrows the current divide between cybersecurity teams and application developers. By the time cybersecurity teams alert developers to a vulnerability they often have moved on to other projects. As a result, developers often lack context because it may have been months since they last looked at the impacted code.

    Of course, the inclusion of DevSecOps best practices should improve the overall state of application security as more responsibility for it shifts left toward developers. However, achieving that goal will require more than just giving developers access to software composition analysis (SCA) tools that only surface vulnerabilities in source code as it is being developed, noted Badhwar.

    In the meantime, the efforts to remediate all existing application vulnerabilities will be measured in years, so organizations need to determine where to focus their efforts. After all, every minute spent developing and deploying patches is less time that can be allocated to building and deploying new code. The trouble is that as more new code is written, the number of vulnerabilities that could be exploited increases and makes a bad situation worse.

  • Rust Momentum Intensifies | Elon Says No WFH

    Rust Momentum Intensifies | Elon Says No WFH

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: People won’t shut up about Rustlang, and Musk mandates Twitter teams return to the office. (more…)

  • A Security Vulnerability Management Guide

    A Security Vulnerability Management Guide

    Living in a container-native world is not easy. Containers have a reputation for being a point of entry for security vulnerabilities for many organizations. In 2015, according to a research paper, over 40% of Docker images distributed through Docker Hub had high-risk vulnerabilities; at that time there were more than 95,000 container images hosted on Docker Hub. Today, there are over 3.5 million container images on Docker, and container security is of even greater concern. In a more recent 2020 study by a team of researchers at the Norwegian University of Science and Technology found container image vulnerabilities in certified and popular packages.

    This is just one example of one kind of security vulnerability. This article will share an introduction to security vulnerabilities and the role of vulnerability management for containers and other artifacts in a continuous integration and continuous delivery (CI/CD) pipeline.

    What is a Security Vulnerability?

    A vulnerability is a weakness or flaw present in software. Security vulnerabilities can be present in application dependencies or operating system (OS) packages. Common vulnerabilities include missing data encryption, buffer overflows, missing authentication for critical functions and insecure interactions between software components.

    There are different risks associated with different types of vulnerabilities. With critical or high-risk vulnerabilities, an attacker who exploits your software has the potential to seriously impact your organization. Risks associated with data breaches impact not only an organization, but also its end users and customers.

    Vulnerability Management Techniques

    Vulnerability assessment practices and tools exist to make detecting vulnerabilities simple, accurate and fast. Some of these practices include:

    • Penetration testing – Penetration testing, or pen testing, allows you to identify security vulnerabilities by attempting to break into your own systems to identify weaknesses.
    • Configuration management – Configuration management involves managing infrastructure configurations and identifying missing patches that leave your software service vulnerable to errors and risks. There are tools that provide infrastructure scanning as-a-service to help detect outdated or misconfigured instances.
    • Container and application Scanning – Allows you to detect vulnerabilities in deployable artifacts and running applications. Some available tools for container scanning include Twistlock, Clair and Trivy.

    These practices help build solid, repeatable vulnerability management techniques across your security and delivery teams. One way to scale these security practices is through security automation. Security automation is the use of technology that performs tasks with reduced manual assistance. It ultimately enables users to apply security decisions automatically and secure processes to deliver more robust applications and infrastructure.

    Security Practices in your CI/CD process

    Security automation is a core tenant of DevSecOps. DevSecOps is short for development security and operations, and it describes how organizations deliver and make security decisions and actions within the development life cycle of their valued deliverables.

    DevSecOps is a way of continuously integrating security in the software development life cycle. It’s a way of working and thinking so that security is at the forefront of how security teams deliver business value.

    One way to enable DevSecOps is through your CI/CD pipeline. Today’s enterprises can use CI/CD to accelerate better software delivery, but with that speed it becomes even more important to enable robust security. Vulnerability scanning improves software security while giving individuals across engineering and product teams accountability for each of the processes these teams own.

    Don’t let Security Vulnerabilities Ruin your DevSecOps

    This is a simple, basic introduction to security vulnerabilities and the risks they pose for your organization. There are practices and tools for detecting and reducing security vulnerabilities, and finding ways to incorporate those processes into a CI/CD pipeline is a great way to accelerate your DevSecOps.

  • Survey Sees Long DevSecOps Ahead

    Survey Sees Long DevSecOps Ahead

    A survey of 250 developers working at leading technology companies paints a bleak picture of the current state of application security with 85% admitting applications on average have 10 or more vulnerabilities, with nearly half saying they have on average more than 20 per application.

    Conducted by Contrast Security, a provider of an observability platform for security, the survey also finds nearly 50% of application security tools are not integrated into the continuous integration/continuous delivery (CI/CD) pipelines.

    Contrast Security CTO Jeff Williams said it’s clear most organizations have a long way to go before best DevSecOps practices become commonplace. In the meantime, the level of disruption being caused by the need to remediate vulnerabilities remains high. The survey finds 88% of respondents need to stop development work to remediate vulnerabilities at least once a week, with nearly 80% spending too much time triaging and diagnosing application security alerts.

    Nearly three-quarters of respondents also noted their organizations cannot find highly specialized application security experts.

    On the plus side, more than one-third of respondents (36%) said at least one application security metric is among their top four performance measurements. Most (63%) have also deployed an interactive application security testing (IAST) solution.

    Most importantly, 77% of respondents said they want more application security training.

    Williams said ultimately DevSecOps will require an observability platform capable of capturing metrics that are meaningful to developers. Contrast has launched an observability platform for IT security teams that borrows DevOps principles to streamline the management of cybersecurity.

    Achieving and maintaining security is complex because application data flows in and out of disparate systems running in the cloud and on-premises IT environments. IT security teams are forced to navigate a multitude of application programming interfaces (APIs) that have varying degrees of dependencies to ascertain what’s actually occurring in their extended IT environments.

    Contrast enables DevOps teams to instrument their applications with security sensors, which Williams said enables the Contrast Application Security Platform to aggregate data flows spanning multiple applications. That approach also eliminates silos spanning application security testing (AST), software composition analysis (SCA) and runtime application self-protection (RASP) tools installed across an enterprise, said Williams.

    It’s not clear to what degree DevOps teams will add agents specifically to instrument applications to gather security data. However, as more responsibility for application security is shifted left toward developers, it’s apparent legacy approaches to securing applications are being found wanting.

    In the meantime, it’s still early days as far as DevSecOps is concerned even for technology companies, much less the average enterprise. Most IT organizations are just getting started down this path. The issue most of them are coming to terms with is the degree to which they need their DevOps and cybersecurity teams to collaborate. While there may be a need for a lot of interaction between these two teams early on, there may come a day soon when DevOps teams eventually reach a level of proficiency that makes security a natural extension of any quality assurance process.

  • GrammaTech Discovers Vulnerabilities in Third-Party Code

    GrammaTech Discovers Vulnerabilities in Third-Party Code

    GrammaTech today launched a CodeSentry software composition analysis (SCA) for binaries that inventories third-party code used in custom applications and identifies known vulnerabilities.

    Vince Arneja, chief product officer for GrammaTech, said the bulk of custom applications today are made up of binaries based on components developed by a third-party that comes in the form of open source, commercial-off-the-shelf (COTS) or existing custom software.

    CodeSentry detects these components and vulnerabilities associated with third-party code, including network components, graphical user interface (GUI) components or authentication layers. It uses deep binary analysis to create a detailed software bill of materials (SBOM) and a comprehensive list of known vulnerabilities.

    Arneja said that as responsibility for security continues to shift left toward developers, there is a need for tools such as CodeSentry that make it easier to identify vulnerability issues in binaries because many developers may not have access to the underlying source code used to construct the binary. CodeSentry identifies components present in native binaries using a range of matching algorithms to gather version number ranges, create an SBOM and provide links to CVE and CVSS scores, said Arneja.

    CodeSentry extends algorithms that GrammaTech developed to detect components in applications, including strings used in natural language processing. It maps components to multi-dimensional vectors and compares them to vectors derived from the components. The upload interface for the tool accepts native binaries, zip files and other archives. Once those files are loaded, CodeSentry analyzes the code that will run rather than the build environment to reduce the number of false positives that would be generated in build environments or components that are not actually being employed.

    GrammaTech next year intends to make CodeSentry available via a software-as-a-service (SaaS) platform, noted Arneja. GrammaTech ultimately envisions CodeSentry being employed as part of DevSecOps workflows driven by a continuous integration/continuous delivery (CI/CD) platform using a set of open application programming interfaces provided by the company, said Arneja.

    While there’s a lot of focus these days on melding DevOps and cybersecurity workflows as part of an effort to embrace best DevSecOps practices, the easiest vulnerability issue to resolve is the one that never existed in the first place. As developers gain access to cybersecurity tools, the number of vulnerabilities making it into applications should significantly be reduced in the months ahead. The challenge IT leaders face is making sure developers have access to those tools, which in turn will ultimately boost the confidence level cybersecurity teams have in application developers, who are often viewed as the primary cause of the problems cybersecurity teams are trying to resolve.

    Regardless of how IT organizations achieve that goal, the return on that investment is likely to be substantial. The amount of time and effort IT teams spend tracking down vulnerabilities that are much more expensive to fix after an application is deployed in a production environment is incalculable.

  • Strengthen API Security With These Tips and Patterns

    Strengthen API Security With These Tips and Patterns

    If you haven’t noticed, digital organizations are building more and more APIs. ProgrammableWeb tracks more than 23,000 public web APIs at the time of writing, and the API market is estimated to be worth $5.1 billion by 2023. Building with APIs increases internal interoperability, reduces development time and can extend product functionality tremendously. In short, the value of APIs is rising. However, opening up with APIs brings security caveats that, if not addressed, could result in serious breaches that negate these benefits.

    I recently spoke with Roey Eliyahu of Salt Security to get his take on the top security concerns for API-enabled companies, and how organizations can safeguard their services. In short, he recommends thoroughly cataloging and understanding your API inventory, designing for legal challenges and mitigating OWASP’s top 10 API security vulnerabilities.

    Challenges for API Security

    APIs have been called “the next frontier in cybercrime.” Rightly so, as API breaches continue to pop up nearly every day. Take the recent API vulnerabilities at Cisco Systems, Shopify, Facebook, U.S. presidential campaign apps, and GCP as evidence. The most infamous was likely the Equifax breach—not enforcing formats on incoming API calls resulted in a massive data breach, which cost the company a $700 million lawsuit.

    So, why have API breaches increased recently? Well, a few years ago, there were simply fewer APIs. And, these older services exposed less sensitive data. Nowadays, companies typically have many more APIs. Banking applications, for example, might expose hundreds of highly valuable endpoints that are very appealing to hackers.

    Companies also build APIs for different audiences: A 2020 study by SmartBear found 72% of companies develop both internal and external-facing APIs. These APIs could easily hold hundreds of parameters, and with every new method added, a company’s potential attack surface grows considerably.

    3 Steps To Secure APIs

    To mitigate the above API security issues, Eliyahu suggested three main steps: Understand your API inventory, audit against privacy policies and data privacy regulations, and track the most pressing API vulnerabilities like a hawk.

    Know Your API Inventory

    “You need a great inventory of APIs to know your attack surface,” said Eliyahu. Many API providers document their APIs with OpenAPI definitions. But, these files don’t always match the production realities—they may be manually generated or leave out certain methods. “In every organization, there is up to a 40% gap between APIs that are actually deployed versus what has been inventoried,” he said. By maintaining a clearer API inventory, organizations can avoid unprotected shadow IT.

    Include Legal Auditing

    A change to an API could result in a change in how it collects user information. Updates involving sensitive data could break privacy policies or regulations such as GDPR. “After you have an inventory, you need to map all parameters manually,” said Eliyahu. He recommended performing a legal audit against your API inventory and establishing a repeatable testing process that plugs into a continuous delivery pipeline.

    As API teams release new updates, they must consider security and legal implications earlier on in the development flow. “Now, with CI/CD, these changes have to happen very frequently,” he noted.

    Watch the OWASP API Security Top 10

    There are many known API security gaps. For example, there may not be proper authorization in place, keys could be exposed, unexpired tokens could be hijacked and so on. Thankfully, OWASP has compiled a resource of top API security vulnerabilities, which Eliyahu and many others in the API economy have rallied behind. “The world should move to adopt the OWASP issues,” he said. These vulnerabilities are as follows:

    1. Broken Object Level Authorization
    2. Broken User Authentication
    3. Excessive Data Exposure
    4. Lack of Resources & Rate Limiting
    5. Broken Function Level Authorization
    6. Mass Assignment
    7. Security Misconfiguration
    8. Injection
    9. Improper Assets Management
    10. Insufficient Logging & Monitoring

    Using AI To Go Beyond ‘Whac-A-Mole’

    Plugging these above holes is a good start. However, these are only defensive measures against known patterns; they aren’t helping you keep guard for nuanced attack types. Ideally, security systems should stop cyberattacks before they even get started.

    Yet, Eliyahu recognizes a big gap in how APIs are monitored. Organizations “don’t have proper tools to know who is looking for vulnerabilities,” he said. “Tools are typically not that advanced. They mainly look for injections and known patterns.”

    Imagine a hacker probing an API. They will likely do so by trial and error, testing undocumented endpoints, sending malformed requests and so on. “They need to probe for hours or days before they find something,” said Eliyahu. If an AI could detect these odd attempts in minutes or seconds, IT could significantly reduce risk.

    Security solutions should thus leverage big data and AI to create baselines of typical behavior, then deter malicious activity the millisecond any nefarious probing begins. Eliyahu said such a security AI must consider dozens of behaviors such as, How is the API being accessed? What parameters are being used? What are the relationships between parameters? What is the flow of API calls? What type of data can be exposed?

    Instead of waiting for a breach to occur, an AI-enabled API security monitoring could instantly pause behavior deemed “out of the norm” by referencing a knowledge base that’s constantly refined using machine learning. Because, if you are only blocking malicious actors without knowing how you need to improve API security posture, “you are just playing Whac-A-Mole,” said Eliyahu.

    DevSecOps Requires API Security Forethought

    Mark O’Neil, analysis at Gartner, predicted that by 2021, 25% of organizations with public APIs will have discontinued or rebooted their public API strategy, citing security concerns as a common breaking point. APIs are now at the core of many application developments. Yet, without the proper DevSec proposition, teams risk wasted efforts and costly breaches.

    To summarize, here are our tips on API security:

    • Ensure everything is well-documented: API inventories cannot be audited if undocumented. Shadow APIs increase the likelihood of an attack.
    • Watch the top 10 OWASP vulnerabilities: These points are foundational to API security. Though not a cure-all, they present a starting point.
    • Build a security and legal review process: Ensure APIs are never deployed without the proper security review. Create validation systems that plug into continuous development processes, so new versions are never breaking privacy policies.
    • Each API is unique: Another thing to keep in mind is each API is unique. Therefore, API security monitoring also requires more context into unique business logic.
    • Continuously monitor your APIs: Continuous search for anyone looking for vulnerabilities.
    • Remove deprecated APIs: Remove old API versions. “You need a mechanism to identify and remove old API versions.” Otherwise, “zombie APIs will bite you!”
    • Learn from the attacks you block: Don’t just play Whac-A-Mole. “You need a mechanism to learn from attacks you block.”
  • Why We Need a Software Bill of Materials Industry Standard

    Why We Need a Software Bill of Materials Industry Standard

    The SBOM concept is part of is an industry-led, multi-stakeholder process to improve software component transparency

    Have you ever gotten a recall notice for the vehicle you drive? Perhaps your car or truck was part of the big recall on airbags a few years ago. It’s standard procedure for auto manufacturers to notify owners of their vehicles when a component is defective and needs to be repaired or replaced. This is true even if the component was made by a third party because it’s still part of the overall makeup of the vehicle.

    Such recalls are possible because manufacturers keep a bill of materials to know every single original thing, including physical parts and internal software, that goes into each vehicle. Title registration records kept by government agencies keep track of current owners of the vehicles. When a recall is necessary, it’s possible to identify which vehicles are affected and who owns them.

    Now the computer software industry is undertaking a similar effort to track individual components such as libraries, executables or source code that go into a software program. Initiated by the National Telecommunication and Information Administration (NTIA), the effort is an industry-led, multi-stakeholder process to improve software component transparency. The NTIA working group is establishing a shared vision of transparency and a “software bill of materials,” or SBOM.

    What Is a Software Bill of Materials?

    An SBOM is effectively a list of ingredients that makes up a software program or application. Like the auto industry, where components come from hundreds or thousands of suppliers, modern software is stitched together from bits of code and subroutines from numerous sources, including open source and commercial solutions. Reusing software code like this means developers don’t have to create everything from scratch themselves. It’s a great time-saver and a very efficient way to develop applications.

    Fig. 1: Software component relationships

     

     

    Source: www.ntia.gov

    A software bill of materials identifies and lists all software components, information about those components and the relationship between them. Figure 1 below illustrates this concept. The chart on the left shows the information that is tracked, while the diagram on the right illustrates the relationships of the software components.

    As the NTIA working groups go through their development phases, they are mindful of the inherent complexity of building and maintaining a verifiable software components list. Issues they are currently working on include how to automatically generate an SBOM and keep it up to date; what standard data format to use for the information; how to distribute an SBOM to someone who acquires a software program or application; and how to verify the authenticity of the data in the components list and their inherited dependencies. The intent is to define specifications that can be used worldwide by both developers and consumers of software. The adoption of SBOM by individuals and companies writing open source software will be key to the initiative’s success.

    The Need for a Software Bill of Materials

    There are several benefits to establishing greater transparency of what code components are in software. Most importantly, it allows companies to control risk by enabling earlier identification and mitigation of vulnerable systems or license infringing source code. Further, it incentivizes secure software development practices by enabling developers to better vet the code they are embedding into their own work. For software consumers, greater transparency supports informed purchasing decisions, especially where compliance with software licensing requirements is concerned.

    Perhaps the greatest value of having a verified SBOM is in the realm of cybersecurity and risk mitigation.

    According to industry studies, the average codebase contains hundreds of open source software components, and the majority of those codebases contain at least one vulnerability. Thus, having insight into code components and their vulnerabilities is critical.

    Once you know precisely what components are in your software, you can get a clear vision of the risk factor this specific bill of materials brings to your environment when it runs. What’s more, the risk factor can change whether or not something in the software bill of materials changes since new vulnerabilities are discovered on a daily basis. The only way to know if you are affected is by having this level of transparency.

    This means of risk assessment is especially relevant when changes are attributed to insider or outsider threats. An insider threat occurs when an internal employee changes something without understanding the full impact of that change on the overall risk; for example, installing a foreign application to SBOM considered to be shadow IT. An outsider threat occurs when an attacker injects malware into your server or a device and tries to make it look like a legitimate component of your system by replacing or introducing a new software component. Either way, expecting to have one component and actually having another introduces a lot of risk to your system.

    Cybersecurity companies will be able to develop solutions that can consume the SBOM in a standard way and cross-reference it with everything running on the system, including the reference to known or new vulnerabilities in the listed software components, and augmented by threat intelligence. Recommendations for mitigations such as software patching can then be put forward. This is commonly called a healing process. In some cases, auto-remediations steps can be taken, such as blocking the malicious software from running until it can be removed.

    Governance over software licenses can be improved through SBOM adoption. Every bit of software comes with a license that dictates the legal use and distribution of the software. The snippets of code in a supply chain that comprises a complete application can have many different licenses for the individual components. Any company that deploys that application has a legal obligation to comply with the licenses. Without a software bill of materials, there may be no way to know what the licenses require, or how to comply with them. 

    Beyond Software: Devices, Too

    There’s another concept that goes beyond just software known as a digital bill of materials, or DBOM. A DBOM extends to the hardware configuration and its embedded firmware and includes the interaction between the components, i.e., the behavioral context. A DBOM would collect the same sort of knowledge about hardware devices and network communication patterns to understand the context of the software materials running on the device. This would apply mostly to IoT devices that otherwise are challenging to monitor, update and protect.

    When you buy a device, you are essentially buying a black box because you don’t know exactly what’s going on inside. If you install it on your network, you don’t know what risks come with this black box. If you knew the risks, you could put mitigations in place. Thus, it’s important to motivate the device manufacturers to get behind the adoption of both SBOM and DBOM specifications and help them recognize how it can improve their operations and security posture. There is value in complying with security certification requirements such as ETSI, allowing their end users to understand the risks they are assuming, and empowering them with the ability to mitigate these risks.

    The medical technology industry has been at the forefront of creating a proof of concept initiative in 2019 to understand the role that SBOMs can play in managing the operational and cyber risks associated with medical devices. Working together, device manufacturers and healthcare providers demonstrated the feasibility of SBOMs by generating, sharing, and using data to improve security practices in pre-defined use cases. NTIA is applying the lessons from that PoC to develop industry-agnostic specifications for the applications of software bills of materials.