The post Beyond Patching: How to Secure Medical Devices and Meet FDA Compliance Without Changing Code appeared first on RunSafe Security.
]]>Key Takeaways:
- Legacy devices can’t be patched easily, but compensating controls provide alternatives.
- SBOMs are critical for transparency and accountability.
- The FDA now mandates secure development and life cycle planning.
- Cybersecurity and patient safety are inseparable—breaches harm care.
- Collaboration is the only sustainable path forward.
In healthcare cybersecurity, one of the biggest challenges is protecting medical devices that are difficult to patch and written in memory unsafe languages. Unlike web applications or mobile software, which can be updated overnight, medical devices are often built to last 10–15 years and aredesigned for reliability and patient safety—not constant code revisions.
Yet cyber threats are growing, and FDA regulations are tightening. Manufacturers and healthcare providers are now under pressure to secure legacy systems while keeping patients safe. The question is: how can this be done without rewriting a single line of code?
This was the focus of a recent episode of Exploited: The Cyber Truth, featuring Phil Englert (VP of Medical Device Security at Health-ISAC) and Joseph M. Saunders (Founder & CEO of RunSafe Security). Their insights offer a practical roadmap that blends compensating controls, regulatory awareness, and industry collaboration.
The Reality of Legacy Devices: Built to Last, Hard to Secure
Medical devices weren’t designed with today’s cybersecurity challenges in mind. Hospitals rely on equipment that often stays in service for a decade or more, from MRI machines to pacemakers, because replacing them isn’t financially or operationally feasible. These devices also run on limited computing resources and cannot tolerate downtime, making traditional patching nearly impossible.
As Englert explained, “We’ve painted a target on our back” by connecting these devices to networks for efficiency and data sharing but without always providing the necessary safeguards. That combination of longevity, limited resources, and operational necessity makes securing these devices a unique and ongoing challenge.
Security Without Code Changes: What It Really Means
When patching or rewriting isn’t an option, the focus shifts to compensating controls, or ways to secure devices without touching their software, as well as opportunities for code protection.
- Monitoring: Establishing real-time visibility into device activity to catch anomalies early.
- Segmentation: Isolating devices so that a breach doesn’t cascade across the network.
- Code Protection: Secure embedded devices in real-time to prevent attacks.
These approaches are not one-size-fits-all. The strategy for an implanted pacemaker is very different from that for a helium-filled MRI machine. But the principle remains: if you can’t harden the device itself, you must harden its environment.
SBOMs: Building Trust Through Transparency
Another theme from the discussion was the rise of Software Bills of Materials (SBOMs). Much like a nutrition label on food, SBOMs give visibility into the “ingredients” inside a medical device. This transparency allows healthcare providers to quickly assess whether known vulnerabilities, like Log4j, impact their devices, hold manufacturers accountable, and make smarter, risk-based decisions about deployment.
As Saunders noted, SBOMs are most valuable when generated close to the point of software production, ensuring accuracy and reliability.
FDA Compliance: Guidance Becomes Mandate
For years, FDA cybersecurity guidance was considered “best practice.” That changed in December 2022 when Congress gave the FDA statutory authority over device cybersecurity under the PATCH Act. By March 2023, manufacturers were required to follow a secure software development lifecycle, account for the full environment in which devices operate, and maintain controls and documentation throughout the device’s lifespan.
This represents a major shift. Compliance is now enforceable, and the focus has expanded from protecting data to ensuring patient safety across interconnected healthcare ecosystems.
Why Patient Safety Is the True Bottom Line
Cybersecurity lapses aren’t abstract IT problems—they have real consequences for patient outcomes. Studies show that clinical performance can decline for up to 18 months following a hospital breach, as resources are diverted to recovery efforts. The “blast radius” often extends beyond one hospital, affecting neighboring facilities that absorb overflow patients.
Among organizations that experienced cybersecurity incidents affecting medical devices, 75% said that cyber incidents caused at least a moderate patient care impact. 46% required manual processes to maintain operations and 24% required patient transfers to other facilities.
As Saunders emphasized, “Cybersecurity is an enabler of patient safety.” Even the most advanced medical care can be undermined without strong cybersecurity practices in place.
Collaboration: The Missing Piece
Perhaps the most actionable takeaway is that no single organization can address these challenges alone. Manufacturers, healthcare providers, regulators, and third-party service organizations all have roles to play.
Practical steps include:
- Negotiating stronger controls before adopting new devices.
- Sharing information through groups like Health-ISAC.
- Starting small—building inventories, mapping data flows, and tightening controls incrementally.
Englert summed it up best: “80% of anything is better than 100% of nothing. Start where you can with the resources you have.”
For more insights on medical device cybersecurity, download RunSafe’s 2025 Medical Device Cybersecurity Index.
The post Beyond Patching: How to Secure Medical Devices and Meet FDA Compliance Without Changing Code appeared first on RunSafe Security.
]]>The post The Wild West of C/C++ Development & What It Means for SBOM Generation appeared first on RunSafe Security.
]]>Unlike modern languages with centralized package managers, standardized toolchains, and strict conventions, C/C++ operates like the Wild West. Developers can link in dependencies in a variety of ways, from copy-paste to remote fetches during compilation. When you need to understand what your software is made of for compliance and vulnerability management, things get sticky fast.
Software Bills of Materials (SBOMs) have become a best practice for managing software supply chain risk as well as a regulatory requirement. But for C/C++, generating a complete and accurate SBOM is notoriously difficult due to the lack of a package manager.
How can developers report on what all is in a C/C++ build? In this article, I look at how C/C++ dependency chaos undermines SBOM accuracy and why a build-time, file-based approach is often the only way to generate trustworthy SBOMs for this legacy language ecosystem.
Listen to the Audio Overview
The Core Problem: No Standardized Dependency Management
Modern ecosystems like Python, JavaScript, and Rust have centralized package registries (e.g., PyPI, npm, crates.io) and well-defined manifest files (e.g., requirements.txt, package.json, Cargo.toml). This allows SBOM tools to easily detect:
- Package name and version
- Download location and hash
- Licensing information
- Dependency relationships
C/C++ has none of this.
Instead, developers rely on informal, ad-hoc methods that leave no clear metadata trail, making it nearly impossible for SBOM tools to determine what’s in your codebase, let alone which components are vulnerable or out of date.
Here are several examples I regularly encounter:
- Copy-paste integration: Some C/C++ libraries officially recommend copying header files or source files directly into a project. Rather than traditional “packages,” the files become part of your project through direct integration.
- Vendor/3rdparty directories: In some instances, developers may copy entire codebases into project trees. In these cases, you miss out on provenance and version information and have no update trail.
- System-level dependencies: Developers sometimes rely on OS-installed libraries, which are external to a repo and easy to miss.
- Git Submodules: Git Submodules allow you to embed one repository within another, creating a nested structure of dependencies. While this provides some level of dependency management, it’s notoriously difficult to work with and is often considered “the best bad solution” by developers. The reliance on commit hashes and inconsistent versioning makes it difficult to reliably map dependencies to CVEs. For example, a submodule version could be “1.2.3” or “v1.2.3” or “tag_name,” which means there is no guarantee you are pulling in the correct information.
- Build system integration: Build systems like Ninja, CMake, and Bazel all have independent ways of creating a notion of dependencies and what needs to be built within a build system. However, it is very open to interpretation of whoever is creating that build system.
- Dynamic dependency acquisition: Perhaps most challenging are dependencies that don’t exist in your source code at all. Some build systems fetch files directly from the web during compilation using tools like wget or curl. These dependencies are invisible until build time.
These challenges result in manual dependency tracking and versioning difficulties, creating security concerns when dependencies are overlooked or forgotten. If your SBOM generator can’t capture these dependencies, you lose visibility into their codebase composition, making it nearly impossible to accurately identify and address security vulnerabilities.
Examples from the Wild West
Git Submodules: Popular, but Poorly Versioned
Despite being widely disliked, Git Submodules are one of the most popular dependency management approaches in C/C++. They provide a way to embed external repositories while maintaining some level of version control.
The challenge with submodules is that they frequently reference Git commit hashes rather than semantic versions. Instead of depending on “library v1.2.0,” you’re depending on commit hash ‘a1b2c3d4’ versus the traditional semantic versioning approach. This makes it difficult to map dependencies to Common Platform Enumeration (CPE) identifiers or vulnerability databases that expect product versions, not version control hashes.
Despite this limitation, Git Submodules are probably one of the easiest dependency approaches to work with from an SBOM perspective, which says something about how challenging the alternatives can be.
SBOM Challenge: Git commit hashes don’t map to CVE databases.
Result: Even if a tool includes the submodule in your SBOM, it won’t be able to determine if it’s vulnerable.
OpenCV: The Third-Party Directory Approach
OpenCV, one of the most popular computer vision libraries, exemplifies the challenges of C/C++ dependency management. OpenCV’s build tree includes a “3rdparty/” directory full of other open source libraries. These are copied into the codebase at a specific moment in time, without any version tracking or external linkage.
Here’s an actual SBOM entry for a file embedded via OpenCV:
{
"name": "predictor_enc.c",
"authors": [
{
"name": "Google Inc"
}
],
<... cut by me for space in message ...>
"copyright": "Copyright 2016 Google Inc",
"properties": [
{
"name": "filePath",
"value": "/plugfest/opencv/3rdparty/libwebp/src/enc/predictor_enc.c"
}
]
},
Upon investigating the repository, you can confirm the “3rdparty/” dependencies are manually included instead of through git submodules or cmake’s built-in `FetchContent` behavior.. As a result, this open source software would be missed and not reported on as a dependency.
SBOM Challenge: No traceable source, version, or update mechanism.
Result: Traditional SBOM tools miss these entirely because they look for package manifests not files buried in a subdirectory.
Mongoose Web Server: Official Copy-Paste Integration
Mongoose, a popular embedded web server, takes an even more direct approach. Their official documentation instructs users to copy exactly two files—mongoose.c and mongoose.h—anywhere in their codebase.
This approach creates several challenges:
- Invisible dependencies: The files might be placed in any directory, making them nearly impossible to detect without examining the actual build process
- Security risk: Updates require manual file replacement, and there’s no automatic way to know when updates are available
- No provenance: Once copied, these files become indistinguishable from the rest of your codebase
SBOM Challenge: Completely invisible unless you trace every file.
Result: These dependencies blend in with the rest of your source tree. Unless your SBOM tool analyzes each compiled file and scans license headers, you’ll miss them completely.
SQLite: Build-Time Fetching from the Web
SQLite demonstrates the most invisible form of dependency management. Some build systems will fetch SQLite source code directly from the web during compilation using commands like wget or curl. This dependency exists nowhere in your source code as it only appears during the build process.
SBOM Challenge: Only exists at compile time.
Result: A static SBOM generator has no way to know the file was downloaded unless it observes the build process in real time.
Why Build-Time SBOMs Are Essential
These real-world examples illustrate why traditional package-based SBOM generation fails for C/C++. When dependencies can be copied directly into source trees, embedded as Git Submodules, fetched dynamically during builds, or integrated through copy-paste instructions, they are all too easy to miss.
To overcome these challenges, SBOM tools must watch the build process itself and not just analyze the source code or look for packages. A file-based, build-time SBOM generator tracks every file that is compiled, linked, or fetched, and extracts metadata like:
- Provenance information from license headers and copyright notices in source files. This is information that most open source projects include and that meets minimum SBOM requirements.
- All included dependencies regardless of how they were integrated into the project.
- Build-specific dependencies that vary based on compile-time configuration. It will show only what’s actually used rather than what’s available.
- Dynamically fetched components that don’t exist in source code but are pulled during the build process.
Every file used in a build gets recorded, providing visibility into the actual composition of software. That visibility leads to better vulnerability identification, less software supply chain risk, and compliance with SBOM regulations.
Working With C/C++, Not Against It
Having built a C/C++-specific SBOM generator at RunSafe, I’ve learned that you can’t force C/C++ dependency management into the expected package manager approach. And you shouldn’t try.
C/C++ development is complex and full of legacy habits that defy modern package management. What we need are tools that support the embedded C/C++ world. When we try to force this rich, complex, legacy ecosystem into modern packaging paradigms, we lose a lot of critical information. RunSafe’s build-time, file-based approach aims to capture that missing information.
The Wild West of C/C++ development isn’t going away. But with the right tools and approaches, we can bring order to the chaos without losing the flexibility that makes C/C++ so powerful in the first place.
What unconventional build systems have you encountered in your C/C++ projects? Share your stories. The more we understand the chaos, the better we can support accurate, secure, and compliant SBOM generation.
The post The Wild West of C/C++ Development & What It Means for SBOM Generation appeared first on RunSafe Security.
]]>The post The 2025 SBOM Minimum Elements: A Turning Point But Embedded Systems Still Risk Being Left Behind appeared first on RunSafe Security.
]]>Key Takeaways
- The 2025 SBOM minimum elements represent significant progress since the 2021 baseline.
- New fields, such as license, hashes, and generation context, push SBOMs beyond check-the-box compliance.
- Licensing data closes a critical blind spot in software supply chain risk management.
- Generation context highlights build-time SBOMs as the industry gold standard.
- Embedded software remains at risk of being overlooked unless file-level SBOMs are explicitly recognized.
In August 2025, the Cybersecurity and Infrastructure Security Agency (CISA) and the Department of Homeland Security (DHS) released a new draft of the Minimum Elements for a Software Bill of Materials (SBOM). It’s the first major revision since 2021, when the National Telecommunications and Information Administration (NTIA) outlined a simple baseline of just seven fields.
The new draft is a genuine turning point. It raises the bar for SBOMs, pushing them beyond check-the-box compliance and closer to being a real tool for managing risk. But while these changes are a big step forward, they still leave embedded systems—built largely in C and C++—struggling to fit into a framework designed with modern package-managed software in mind.
As Kelli Schwalm, SBOM Director at RunSafe Security, puts it: “The recommended 2025 SBOM minimum elements show how far the industry has come since 2021. We’ve moved from a theoretical checklist to practical requirements that reflect how SBOMs are actually used in the real world.”
However, Kelli warns, the implicit assumption in the draft recommendations is that a software component equals a package. For embedded systems, that’s not the case. Without explicit recognition of file-based SBOMs, we risk leaving critical systems out of the picture.
Listen to the Audio Overview
What Are SBOM Minimum Elements?
An SBOM is an ingredients list for software. To be useful, every SBOM must include certain key data fields, or the minimum elements.
In 2021, the NTIA’s list was a good starting point, but as software development has evolved, it is now far too basic: name, version, identifier, timestamp.
To reflect the reality of software development today, the 2025 draft adds fields like:
- License: Critical for compliance and security obligations
- Component hash: Cryptographic accuracy, pushing toward automation
- Generation context: Identifying whether an SBOM was created at source, build, or binary stage
- Dependency relationships: Clarifying how components connect
The updates reflect how organizations are actually using SBOMs today to manage software supply chain risk.
Why the New SBOM Minimum Elements Guidance Matters
From “Check-the-Box” to Automation
The 2021 requirements made it possible to deliver a barebones SBOM with nothing more than an Excel spreadsheet. Those quickly went stale and carried little value. The new requirements—particularly hashes, license data, and generation context—make that shortcut nearly impossible, forcing a move toward automated SBOM generation.
As Kelli explained: “By requiring more fields—hashes, authorship, generation context—CISA is making it almost impossible to get by with an outdated Excel spreadsheet. These new elements push the industry toward automated, accurate SBOM generation, which is the only way to keep pace with today’s threat environment.”
Licensing Finally Gets Its Due
License information is now a minimum requirement. Licensing is a compliance issue, but license restrictions can directly impact how software can be used or redistributed. By including it, CISA and DHS are addressing a real-world gap that often goes unnoticed until it becomes a legal or operational problem.
“Licensing impacts how organizations use and share software,” Kelli said. “Ignoring it in SBOMs left a blind spot in the software supply chain, and closing that gap is long overdue.”
Generation Context Raises the Quality Bar
Including generation context—stating where in the lifecycle the SBOM was created—is a small addition with outsized impact. For example, “Build-time SBOMs give the clearest and most accurate view of software,” Kelli said. “This requirement could pressure suppliers to deliver them, raising the quality bar across the ecosystem.”
By making generation context mandatory, the draft puts pressure on suppliers to produce higher-quality SBOMs and discourages binary-only or “black box” approaches.
Compare SBOM generation approaches.
RunSafe’s Perspective
RunSafe sees the 2025 SBOM minimum elements as a much-needed course correction. They reflect four years of learning, discourage paper-thin compliance practices, and push the industry toward automated, accurate, and timely SBOMs.
But gaps remain, especially for embedded systems. Most federal guidance still implicitly equates “software component” with “package.” For modern applications built with package managers, that’s fine. For embedded devices, it’s a problem.
“Most federal guidance still assumes software components come neatly packaged, but embedded software in C and C++ rarely works that way,” Kelli said. “File-level SBOMs are harder to generate, but they’re also where you get the most precise vulnerability data.”
That precision matters most in embedded systems—the software inside medical devices, critical infrastructure, and defense technology—where false positives waste time and false negatives risk lives.
“If we don’t account for embedded use cases, we risk leaving out some of the most critical systems,” Kelii said.
RunSafe believes the draft’s generalized fields are a step in the right direction, but federal guidance should go further. It should explicitly recognize that SBOMs can be generated at the file level, not just at the package level, and that embedded contexts demand this granularity.
Raising the Bar for Software Supply Chain Security
The 2025 SBOM minimum elements draft is a milestone. It raises expectations, improves accuracy, and pressures suppliers to move beyond token compliance. That’s progress.
But for SBOMs to fulfill their promise across the entire software ecosystem, we must ensure embedded systems are not left behind. File-level SBOMs are essential for securing the most critical software our society relies on.
At RunSafe, we applaud the direction of the new guidance and will continue to advocate for embedded-first thinking in SBOM guidance. The security of the software supply chain depends on it.
Learn more about RunSafe’s approach to SBOM generation and software supply chain security. Download our white paper or view our SBOM tool comparison.
The post The 2025 SBOM Minimum Elements: A Turning Point But Embedded Systems Still Risk Being Left Behind appeared first on RunSafe Security.
]]>The post What Is a SBOM? Binary vs Build-Time vs Source Code appeared first on RunSafe Security.
]]>
Software Bills of Materials (SBOMs) are a detailed inventory of all the components—open source, proprietary, and third-party—used within a software application. SBOMs play a key role in ensuring software integrity, managing security risks, and strengthening software supply chain security.
As SBOM requirements expand around the globe, organizations need to be able to generate SBOMs quickly and efficiently to minimize development lifecycle overhead. Depending on the type of software projects you develop and maintain, there are different types of SBOM generation techniques that will work best in different scenarios. Additionally, the way an SBOM is generated affects its accuracy and completeness and your visibility into software vulnerabilities.
Here, we break down the three main types of SBOMs, why SBOMs are important for vulnerability identification and management, and special considerations for C/C++ projects.
Binary-Based SBOMs: The Pre-Packaged View
Binary-based SBOMs are generated by analyzing compiled software, focusing on the final product rather than the source code or build process. The approach works by examining the binary to identify its components and dependencies.
Binary-based SBOMs are useful for legacy software and older systems where source code is either unavailable or inaccessible. They also enable the analysis of third-party software components without requiring access to their source code.
However, relying solely on binary analysis often results in SBOMs that lack critical details that can only be captured during the build process, the most notable example being the existence of statically linked libraries. Some auxiliary data is also lost during compilation, making it difficult to trace the origin and history of certain components due to limited provenance information.
The lack of visibility often leads to a high rate of false positives, as accurately determining the contents of a binary without insight into the actual build is inherently challenging. While valuable in specific scenarios, binary-based SBOMs are less precise compared to other SBOM generation methods.
Key takeaway: Binary-based SBOMs provide a practical solution for managing legacy systems or third-party components. However, they typically lack the depth and accuracy of SBOMs generated from source code or during the build process, often resulting in less detail and a higher likelihood of false positives.
Source Code SBOMs: A Static View with Broad Coverage
Source code-based SBOMs are generated by analyzing a software’s source tree for a specific target, offering a comprehensive view of the components involved in the development process. This method has several notable advantages.
First, it provides complete visibility into the source code, ensuring a thorough inventory of all potential components that could be included in the software. It also offers direct access to valuable metadata, such as licensing and copyright information, which is critical for compliance and legal requirements. Additionally, analyzing source code is less computationally intensive than its more involved build-time SBOM counterpart, as it involves simpler, less resource-demanding operations.
However, the source code-based approach comes with its own set of challenges. A key issue lies in the complexity of build configurations. Since this method examines the source tree rather than the final software build, it may fail to accurately reflect the configurations used to generate the actual binaries. This misalignment can result in discrepancies between the SBOM and the final product. Conditional compilation further complicates matters, as accounting for different compilation paths in large, complex codebases with multiple configurations can be particularly challenging.
Another limitation is its inability to capture runtime dependencies—external components that are dynamically fetched during the software’s operation. Consequently, source code-based SBOMs often over-report, including components that may not make it into the final binary and creating unnecessary noise. This can lead to false positives, where components that are in the source code are flagged even though they will not be in the final build and so do not present any business risk.
Key takeaway: Source code-based SBOMs provide greater visibility into all components of a codebase, making them valuable for compliance, licensing, and early development analysis. However, they still miss out on providing the complete picture of the final product and have a strong chance of false positives by not accounting for build configurations and runtime dependencies.
Build-Time SBOMs: The Complete Picture
Build-time SBOMs are considered the most accurate and efficient method for tracking software components because they are generated during the compilation process, providing a detailed and reliable view of all the components included in the final software build.
Build-time SBOMs execute against the precise components that will be in the build and only contain the relevant libraries and the specific sub-components used in said libraries during the building of the compiled output. Build-time SBOMs are also able to capture all external or linked resources that are only included at build time.
The precision of build-time SBOMs reduces alert fatigue and saves engineering teams time by minimizing false positives and eliminating the need to investigate reported vulnerabilities on components that will not be in the final build and that do not present a risk to production.
When implementing build-time SBOMs, look for solutions that easily integrate into your CI/CD pipeline and existing development workflows. For them to be useful, they must fit smoothly into automated workflows without adding extra complexity or causing delays. Also consider performance. Build-time SBOMs increase accuracy, but should not come at the cost of slowing down build times significantly.
Key takeaway: Build-time SBOMs offer the most precise and comprehensive tracking of software components, making them essential for strengthening software supply chain security and minimizing false positives. They can also be created for legacy software where the source code is readily available. To maximize their impact, choose solutions that seamlessly integrate into your CI/CD pipeline.
Choosing Your SBOM Generation Tool: Implications for Vulnerability Identification
The type of SBOM you choose can significantly impact your software security efforts. When selecting an SBOM generation tool, consider your specific needs, access to source code, and desired accuracy level. For most modern development environments, build-time SBOMs will provide the most value and the clearest picture of your software’s actual composition. A complete and accurate picture of your software’s composition enables more effective vulnerability identification and risk management, allowing you to:
- Maintain strong software supply chain security
- Efficiently identify and address vulnerabilities
- Deliver more secure products
- Meet SBOM regulatory compliance requirements
SBOM Generation for C/C++ Projects
Generating SBOMs for C/C++ projects is challenging because of the complexity and legacy nature of these ecosystems. It is not simple to gather the data and information needed to create comprehensive and accurate SBOMs.
The typical approach is to use package-based component mapping. However, unlike modern languages like Python or Rust, C/C++ doesn’t have a widely adopted package manager, making it difficult to automatically track dependencies.
Without the availability of package managers, each C/C++ SBOM generator has to take an unorthodox approach to SBOM generation, whether it’s by relying on the compiler’s use of files during the build process, the generation of symbols during compilation, or methods yet to be developed. However, each method provides absolute clarity into the build process as it is happening, resulting in high fidelity with no package manager required.
A build-time approach is ideal for real-time and embedded software, giving visibility into your software components with a full dependency tree.
Build-Time SBOMs Lead the Way in Modern Software Security and Compliance
Selecting the right SBOM generation method is vital for ensuring secure and compliant software products. The key to success is choosing an SBOM generation strategy that fits your specific needs, factoring in elements like source code accessibility, development processes, and desired accuracy.
No matter the approach, adopting strong SBOM practices is essential to meet regulatory standards, effectively manage vulnerabilities, and deliver secure, resilient software.
The post What Is a SBOM? Binary vs Build-Time vs Source Code appeared first on RunSafe Security.
]]>The post A Guide to SBOM Requirements Around the Globe appeared first on RunSafe Security.
]]>Over the past several years, regulators around the globe have begun issuing Software Bill of Materials (SBOM) requirements and standards in an effort to strengthen software security. SBOMs are a detailed inventory of all the components—open source, proprietary, and third-party—used in a software application. SBOMs provide visibility into software components and are a valuable tool for strengthening software supply chain security and traceability. Why are regulators focusing on SBOMs now, and what does that mean for your software development practices? This guide will take a look at SBOM requirements around the globe, their origins, and emerging global trends. Whether you’re a software developer or part of a security-focused team, staying updated on SBOM regulations is critical for compliance and safeguarding your software ecosystem.
Why SBOMs Are Becoming a Must-Have
SBOM requirements didn’t emerge in a vacuum. They were born in response to two major software supply chain attacks, the most infamous of which was the SolarWinds attack of 2020.
1. The SolarWinds Attack of 2020
The SolarWinds attack marked a turning point in cybersecurity history. This sophisticated supply chain compromise impacted over 18,000 organizations, including multiple U.S. federal agencies. Attackers leveraged vulnerabilities in SolarWinds’ software updates to gain unauthorized access, demonstrating how a lack of visibility into source components could have devastating consequences. The fallout from this attack placed a spotlight on SBOMs as a tool to identify and mitigate risks in software supply chains. By providing detailed inventories of software components, SBOMs have since emerged as a foundational element of secure software development practices.
2. The Log4Shell Vulnerability
Another major wake-up call came in late 2021 with the discovery of the Log4Shell vulnerability. This critical flaw in the widely-used Log4j library exposed organizations worldwide to potential exploitation. Many companies scrambled to assess their exposure, yet their lack of comprehensive SBOMs caused unnecessary delays in response times. These incidents collectively underscored the critical importance of having a full inventory of software dependencies to identify vulnerabilities quickly and ensure timely remediation.
The Evolution from Request to Requirement
Executive Order 14028 (2021)
Following the SolarWinds attack, the White House issued Executive Order (EO) 14028 on Improving America’s Cybersecurity in 2021. The EO required federal agencies to request SBOMs from software vendors. The National Telecommunications and Information Administration (NTIA) outlined the “Minimum Elements for an SBOM,” which include:
- Data fields (component name, version, supplier)
- Automation support for machine-readable formats
- Practices for SBOM updates and distribution
The mandate brought awareness to the necessity of SBOMs, but lacked strong enforcement mechanisms, serving as a framework for how to enforce SBOMs in the future.
CISA Guidance (2024)
In 2024, the The Cybersecurity and Infrastructure Security Agency (CISA) expanded on the original guidance from the NTIA, issuing the framework: “Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM).” The CISA framing document is the most up-to-date guidance for how to build an SBOM, including direction on what to include in an SBOM and processes for SBOM creation and exchange. While the CISA guidance is not an enforcement directive, these recommendations have transformed into hardline requirements enforced by specific federal agencies, which we review below.
Key U.S. SBOM Requirements Today
FDA Cybersecurity in Medical Devices Requirements (2023)
In 2023, the FDA updated their guidance on “Cybersecurity in Medical Devices.” The FDA now requires medical device manufacturers to submit SBOMs during premarket reviews for “cyber devices” that connect to the internet or are sensitive to cybersecurity risks. These SBOMs must include:
- Lifecycle information
- Vulnerability assessments
- Remediation plans
U.S. Army SBOM Directive (2024)
The U.S. Army SBOM Directive was released on August 16, 2024 and the SBOM requirements will take effect in February 2025. This directive was issued in the form of a memo detailing the Army’s strategy to mandate the inclusion of SBOMs in most new software contracts. Software contractors and subcontractors will need to supply SBOMs for nearly all software-related contracts, including commercial off-the-shelf (COTS) products.
PCI DSS 4.0 Standards (2024)
PCI DSS 4.0 governs payment card data security and encourages SBOM usage among payment processing software providers.
SBOM Compliance Requirements Around the Globe
1. The European Union
In 2024, the EU adopted the Cyber Resilience Act (CRA), a landmark regulation designed to ensure that hardware and software products with digital elements are secure before they are placed on the market. Under the CRA, manufacturers need to identify, address, and report on vulnerabilities within their products, including mandatory SBOM generation. The CRA covers a range of connected devices, from cameras and appliances within our homes to hardware and software deployed within critical infrastructure.
2. Germany
In 2023, Germany’s Federal Office of Information Security (BSI) adopted Technical Guideline TR-03183 on Cyber Resilience Requirements for Manufacturers and Products. TR-03183 provides detailed requirements for SBOMs with the goal of preparing manufacturers ahead of the upcoming enforcement of the CRA. The guideline specifies minimum fields of information and preferred formats for SBOMs, mirroring the standards set by the U.S. National Telecommunications and Information Administration (NTIA).
3. The United Kingdom
The UK’s National Cyber Security Centre (NCSC) encourages organizations to adopt SBOMs as part of their cybersecurity best practices. While not yet mandatory, NCSC has issued guidelines advocating for SBOMs to improve transparency and mitigate risks in software systems.
4. Australia
The Australian Cyber Security Centre (ACSC) has become a vocal proponent of SBOMs to enhance software supply chain security. Through comprehensive frameworks and recommendations, the ACSC encourages organizations to leverage SBOMs as a key defense mechanism against vulnerabilities.
5. Japan
Recognizing the global move toward SBOM adoption, Japan has launched proof-of-concept projects in collaboration with private industry players. The government plans widespread implementation by 2025, ensuring businesses have time to adapt.
Industry-Specific SBOM Requirements
Various industries face unique SBOM requirements to address specific challenges.
- Healthcare: The FDA mandates thorough SBOMs given the critical implications of the breach of a medical device for patient health and safety.
- Government Contractors: Compliance with Executive Order 14028 is essential for businesses working with federal agencies.
- Critical Infrastructure: CISA guidance is paving the way for SBOM adoption in critical infrastructure like energy and transportation.
- Automotive: Software-driven cars rely heavily on SBOMs to ensure compliance and enhance consumer safety.
What These SBOM Standards Mean for Organizations
The global push for SBOMs reflects a shared understanding of their importance in reducing risk in the software supply chain. While requirements vary in scope, organizations across industries must prepare to align with emerging regulations. Here’s how SBOMs provide real, functional value to businesses worldwide:
1. Improved Security
By tracking software dependencies and components, SBOMs enable organizations to promptly identify and remediate vulnerabilities like Log4Shell or Heartbleed.
2. Simplified Compliance
Legal mandates such as the FDA Cyber Device Rule or the EU CRA mean SBOMs are increasingly non-negotiable for regulatory compliance. Enterprises that embed SBOM practices into their workflows are better equipped for compliance.
3. Enhanced Transparency
SBOMs foster trust between vendors and customers by offering a detailed view of software components. This transparency can serve as a competitive advantage in an increasingly security-conscious market.
4. Proactive Risk Management
SBOMs empower organizations to adopt a proactive approach to software security. By continuously monitoring and updating software inventories, businesses can stay ahead of risks.
Preparing for Compliance
Adopting SBOMs involves several best practices to ensure proper implementation and alignment with regulatory requirements.
Steps to Get Started
- Inventory Existing Software: Conduct a thorough review of existing software to identify components and dependencies.
- Select an SBOM Tool: Choose from industry-leading SBOM generation tools. Look for solutions that support multiple formats, such as SPDX and CycloneDX, as these are commonly recommended by global standards.
- Update Security Policies: Incorporate SBOMs into your organization’s software development lifecycle and establish policies for ongoing updates.
- Train Your Team: Ensure your development and security teams understand how to generate and manage SBOMs effectively.
- Collaborate with Vendors: Require third-party vendors to provide SBOMs as part of contract negotiations.
Businesses that take proactive steps to integrate SBOM practices can better secure their software supply chains while meeting compliance deadlines.
Building the Future of Secure Software
Much like the cybersecurity landscape itself, SBOM regulations are in a state of rapid evolution. Businesses that remain proactive, informed, and adaptive stand to gain the most from this shift toward transparency and accountability.
The post A Guide to SBOM Requirements Around the Globe appeared first on RunSafe Security.
]]>The post Building Trust with Software Bill of Materials (SBOMs) appeared first on RunSafe Security.
]]>The Importance of Transparency
SBOMs and Software Supply Chain Security
RunSafe’s Unique Approach to SBOMs
Building Trust with Software Bill of Materials (SBOMs)
The Importance of Transparency
In our digitally connected era, the software supply chain is the backbone of our modern technology. Software development, from its inception to its deployment, navigates a sophisticated network involving developers, vendors, and users. Lately, this supply chain has become a key concern for both security experts and policymakers. Its intricacy introduces numerous security threats that jeopardize the integrity, confidentiality, and availability of software systems.
Transparency within the software supply chain is crucial for identifying and mitigating these risks. High-profile incidents, such as the SolarWinds and Log4j exploits, have illuminated the severe consequences of opaque supply chains, where hidden vulnerabilities can lead to widespread compromise. By fostering transparency, organizations can gain visibility into their software components, dependencies, and the origins of their code. This visibility is essential for understanding the full scope of potential vulnerabilities and for implementing effective security measures.
At RunSafe, we are addressing these challenges by advocating for comprehensive transparency through the use of Software Bill of Materials (SBOMs). SBOMs provide a detailed inventory of software components, enabling organizations to run an accurate vulnerability assessment. Unlike traditional methods that rely on post-production heuristics, RunSafe generates SBOMs during the build process, offering a more complete and accurate representation of the software composition. This proactive approach not only enhances vulnerability management but also ensures compliance with industry standards and regulatory requirements.
SBOMs and Software Supply Chain Security
In the intricate landscape of software supply chain security, the SBOM plays a pivotal role in enhancing transparency and traceability. An SBOM is a detailed inventory that outlines all the components, including dependencies and associated vulnerabilities, within a software application. This comprehensive catalog is essential for organizations to gain deep insights into their software’s composition and the potential security risks it may harbor.
SBOMs are crucial for several reasons. First, they provide a transparent view of all the software components used, enabling organizations to identify and manage vulnerabilities effectively. This transparency is particularly vital in a landscape where third-party software components are prevalent, as it allows organizations to vet and monitor these components rigorously, thereby reducing the attack surface.
Moreover, SBOMs enhance traceability, allowing organizations to track the origins and updates of each software component. This capability is essential for maintaining software integrity. By knowing exactly what is in their software, organizations can swiftly address any vulnerabilities that arise, mitigating the risk of exploitation.
This approach also aids in compliance and regulatory adherence. Many regulatory frameworks and industry standards now mandate detailed documentation and tracking of software components to ensure security and integrity. By generating comprehensive SBOMs, organizations can readily meet these requirements, avoiding potential fines and sanctions. This not only ensures regulatory compliance but also enhances an organization’s reputation for robust security practices.
The detailed insights provided by SBOMs also enable organizations to implement more effective risk management strategies. By understanding the exact composition of their software, organizations can prioritize their security efforts, focusing resources on the most critical and vulnerable components. This targeted approach to risk management improves the overall security efficacy, reducing the likelihood of successful attacks and minimizing potential damage.
RunSafe’s Unique Approach to SBOMs
RunSafe differentiates itself by generating SBOMs directly at build time rather than relying on post-build heuristics. This method provides a complete and accurate representation of the software composition, capturing all dependencies, including second-order ones that conventional methods might miss. This approach ensures a more detailed and reliable SBOM, enhancing an organization’s ability to manage and mitigate security risks proactively.
By incorporating SBOMs into the software development lifecycle, organizations not only enhance their security posture but also demonstrate a commitment to transparency and accountability. This proactive stance not only helps in compliance and regulatory adherence but also builds trust with stakeholders and customers, reinforcing the organization’s dedication to robust cybersecurity practices.
RunSafe’s method of generating SBOMs at build time sets a new standard in software supply chain security. This approach ensures a more detailed and reliable SBOM, empowering organizations to manage and mitigate security risks proactively.
Building Trust with SBOMs
Integrating SBOMs into the software development lifecycle is a critical step in managing and mitigating security risks inherent in today’s complex software supply chains. SBOMs provide an invaluable tool for maintaining transparency and building trust, ensuring software integrity, and bolstering overall security posture. By generating SBOMs at build time, as RunSafe does, organizations can achieve a more detailed and accurate vulnerability assessment of their software composition, capturing all dependencies and reducing the risk of overlooking critical vulnerabilities.
This proactive approach offers several key benefits. It enhances the ability to identify and address vulnerabilities promptly, thus reducing the window of opportunity for malicious actors. It also fosters a culture of accountability and transparency, which is essential for building trust with customers, partners, and regulatory bodies. As regulatory requirements increasingly mandate detailed documentation of software components, having comprehensive SBOMs at hand ensures compliance and minimizes legal and operational risks.
Moreover, the insights provided by SBOMs enable organizations to implement more effective risk management strategies, prioritizing their security efforts on the most critical and vulnerable components. This targeted approach not only improves security efficacy but also optimizes resource allocation, ensuring that security investments yield the maximum possible benefit.
In an era where digital interconnectivity and dependency are at an all-time high, securing the software supply chain is not just an organizational imperative but a fundamental necessity for safeguarding critical infrastructure. By adopting SBOMs and leveraging innovative solutions like those offered by RunSafe, organizations can fortify their defenses, enhance their resilience against emerging threats, build trust, and pave the way for a safer, more secure digital future.
The post Building Trust with Software Bill of Materials (SBOMs) appeared first on RunSafe Security.
]]>The post Visualizing SBOMs for Embedded Systems: Key Components, Examples, and Takeaways for Cybersecurity appeared first on RunSafe Security.
]]>Understanding and managing software components is crucial for safeguarding against cybersecurity vulnerabilities. A Software Bill of Materials (SBOM) serves as a comprehensive inventory of all components, libraries, and modules used in software applications. SBOMs help organizations identify and address potential security risks efficiently and transparently.
SBOMs are particularly significant in embedded systems, which are integral to numerous critical applications, from medical devices to industrial control systems. Because embedded systems often incorporate a variety of third-party and open-source components, they are susceptible to hidden vulnerabilities. SBOMs give visibility into these components, allowing developers and software manufacturers to get ahead of risk.
What Is a SBOM?
A Software Bill of Materials is a detailed list of all components, libraries, and modules used in a software application. Think of it as an ingredient list for a recipe, but for software. Each entry in an SBOM provides crucial information about the components, including their origin, version, and any known vulnerabilities. This comprehensive inventory is essential for managing software supply chains and ensuring robust security. SBOMs play a pivotal role in providing transparency and accountability for risk assessment in software development.
Why SBOMs Matter in Embedded Systems
Embedded systems are specialized computing systems that perform dedicated functions within larger mechanical or electrical systems. Found in devices ranging from medical equipment and industrial controls to consumer electronics and automotive systems, embedded systems are integral to critical infrastructure. These systems are designed for specific tasks, often operating in real-time and requiring high reliability and stability.
Given their crucial roles in sectors such as healthcare, energy, transportation, and manufacturing, embedded systems are often targets for cyber threats. Their integration into critical infrastructure means that any vulnerability can have far-reaching and potentially catastrophic consequences.
SBOM Example: Key Components for Embedded Systems
For embedded systems, having a comprehensive and accurate SBOM is essential. Below are the key components:
- Component name: Each software component is listed by its name. This includes libraries, frameworks, and modules. Example: libssl.so.1.1.
- Version information: The specific version of each component is noted. Example: Version 1.1.1g.
- Supplier Information: Details about the vendor or author of the component. Example: OpenSSL Software Foundation.
- Licensing information: The type of license governing the use of the component. This ensures compliance with legal and regulatory requirements. Example: Apache License 2.0.
- Component hash: A cryptographic hash (e.g., SHA-256) that verifies the integrity of the component. Example: 3c1a84ab7f23cd8c1e8f4564a2e4f45b234a7d8e92b6ec34b8b9d5c6e8f01234.
- Dependency relationships: Information on how components depend on each other. Example: libssl.so.1.1 -> libcrypto.so.1.1.
- Security and vulnerability information: Known vulnerabilities associated with the components. Example: CVE-2020-1971.
An SBOM for an embedded system might include a line like the following example:
File Component Example from a Build-Time SBOM
Library Component Example from a Build-Time SBOM
GET FULL VISIBILITY INTO THE COMPONENTS IN YOUR EMBEDDED SYSTEMS [START FREE TRIAL]
Creating an SBOM: Top Security Tools and Best Practices
Common tools for generating SBOMs in embedded systems include:
- Syft: A CLI tool for creating SBOMs from container images and filesystems.
- CycloneDX: A lightweight SBOM standard.
- SPDX: An open standard with tools like SPDX-Tools for SBOM creation and validation.
- Black Duck: A comprehensive open-source management tool with SBOM generation features.
- FOSSA: An automated tool for open-source compliance, security, and SBOM generation.
- Endor Labs: Goes beyond traditional SCA tools by not relying solely on package manifests, addressing transitive dependencies effectively.
- RunSafe Security: Generates SBOMs as part of the build process with unique capabilities for C/C++ languages
Best practices for creating effective and comprehensive SBOMs include the following:
- Integrate automated tools into the CI/CD pipeline for consistent SBOM updates.
- List all software components, including dependencies, versions, licenses, and suppliers.
- Regularly update SBOMs to reflect new components and patches.
- Use cryptographic hashes to verify component integrity.
- Include known vulnerabilities (e.g., CVEs) for proactive security management.
- Ensure license compliance for all components.
- Maintain clear documentation and transparency throughout the supply chain.
Using SBOMs to Enhance Embedded Systems Security
Using SBOMs is a proactive strategy for bolstering the security of embedded systems. SBOMs provide a detailed inventory of all software components, including versions and dependencies. This transparency allows security teams to track known vulnerabilities (e.g., CVEs) associated with each component.
By regularly updating SBOMs and cross-referencing them with vulnerability databases, organizations can quickly identify and address security weaknesses. Automated tools can alert teams to newly discovered vulnerabilities, facilitating prompt patching and mitigation efforts.
By analyzing the SBOM, organizations can prioritize security efforts based on the potential impact of each vulnerability.
Challenges and Solutions in SBOM Implementation
Integrating SBOMs into embedded systems faces challenges like managing numerous third-party components, limited processing power, and memory constraints. Tracking component versions and ensuring consistency across environments is difficult, and the lack of industry-wide standards can cause compatibility issues.
Practical solutions include using automated SBOM tools like SPDX and CycloneDX, incorporating SBOM generation into CI/CD workflows, adopting standardized SBOM formats, conducting regular audits, and training development teams on best practices for SBOM creation and maintenance. These strategies help streamline dependency tracking, maintain accuracy, and ensure compatibility in managing software component inventories.
The Future of SBOMs in Embedded Systems
The future of SBOMs in embedded systems is set to transform significantly, spurred by emerging trends, government directives, and technological advancements aiming to bolster security and operational efficiency.
Recent federal directives have underscored the importance of SBOMs in ensuring software security, aligning with NIST Guidance and emphasizing secure software development practices. Automation tools and AI are poised to play an increasingly vital role in SBOM generation, streamlining vulnerability identification and risk prediction.
Future SBOMs are likely to integrate real-time monitoring, machine learning, and big data analytics to enhance integrity and authenticity. Standardization efforts and regulatory recognition are expected to drive broader adoption and interoperability, integrating SBOMs into DevSecOps practices and facilitating early vulnerability detection.
How SBOMs Improve Software Security
SBOMs are essential for securing embedded systems, providing transparency, vulnerability tracking, and risk assessment. As embedded systems play critical roles in various industries, the adoption of SBOM practices becomes paramount for maintaining robust security postures. By integrating SBOMs into your cybersecurity strategy, you can proactively address potential threats and enhance the resilience of your systems.
The post Visualizing SBOMs for Embedded Systems: Key Components, Examples, and Takeaways for Cybersecurity appeared first on RunSafe Security.
]]>The post Securing Critical Infrastructure: The Role of SBOMs appeared first on RunSafe Security.
]]>Securing Critical Infrastructure: The Role of SBOMs
Cybersecurity in Critical Infrastructure: An Overview
Introduction to Software Bill of Materials (SBOMs)
How SBOMs Contribute to Cybersecurity
Types of SBOMs and How They Are Different
Benefits of Build-time and Binary SBOMs
Use Cases for Critical Infrastructure
Taking SBOMs to the Next Level
Securing Critical Infrastructure: The Role of SBOMs
The protection of critical infrastructure is paramount. From power grids to transportation systems, the backbone of society relies heavily on interconnected software systems. However, with this increased reliance on technology comes a heightened risk of cyber threats that continue to increase in frequency and sophistication.
In this blog, we’ll explore the significance of Software Bill of Materials (SBOMs) in fortifying the cybersecurity of our critical infrastructure.
Cybersecurity in Critical Infrastructure: An Overview
Critical infrastructure encompasses various sectors essential to society’s normal functioning, including energy, water, transportation, and communication. As these systems become increasingly digitized, they also become susceptible to cyberattacks. Threat actors, ranging from nation-states to malicious hackers, target vulnerabilities in software systems to disrupt operations, compromise data, and cause widespread chaos.
Introduction to Software Bill of Materials (SBOMs)
A Software Bill of Materials (SBOM) is a comprehensive list of components and dependencies within a software system. Think of it as a detailed inventory that outlines all the ingredients used to build a particular software product, including libraries, frameworks, and third-party modules. SBOMs provide invaluable transparency into the software supply chain, offering insights into the origin and composition of every component.
How SBOMs Contribute to Cybersecurity
The significance of SBOMs in cybersecurity cannot be overstated. These documents serve multiple critical functions:
Enhancing Supply Chain Security: With the growing efficiency of software development outsourcing and third-party integrations, the software supply chain has become increasingly complex. SBOMs enable stakeholders to track every component’s origin and assess its security posture, mitigating the risk of supply chain attacks.
Facilitating Vulnerability Management: By providing a detailed inventory of software components, SBOMs streamline vulnerability management processes. Organizations can quickly identify and address vulnerabilities within their software stack, reducing the window of exposure to potential cyber threats.
Supporting Vulnerability Disclosure and Reporting: Effective communication with customers and stakeholders is essential in cybersecurity. SBOMs facilitate transparent vulnerability disclosure by providing recipients with a clear understanding of the software’s composition and any associated security risks.
Types of SBOMs and How They Are Different
According to the Cybersecurity & Infrastructure Security Agency (CISA), there are multiple types of SBOMs: Design, Source, Build, Analyzed, and Deployed. While each serves a specific and valuable purpose, two types impact the effectiveness of cybersecurity for critical infrastructure: build, Deployed, and Runtime (also called Binary).
Build-time SBOMs are generated during the software build process and offer insight into the components used in the software. Used mostly by product manufacturers and developers, Build SBOMs gather data from source files, dependencies, built components, build process ephemeral data, and other SBOMs to create a releasable artifact.
Binary-based SBOMs provide an inventory of software that is present in a running environment and/or has been executed. It offers infrastructure operators insights into components present in the system and external call-outs or dynamically loaded components.
Benefits of Build-time and Binary SBOMs
Integrating Buildtime and Runtime SBOMs into cybersecurity strategies helps to strengthen the resilience of critical infrastructure systems against cyber threats and ensure the uninterrupted operation of essential services.
While they don’t create security themselves, SBOMs provide the insight needed to secure embedded software, systems, and connected devices by identifying the areas of opportunity to improve security.
Both Build-time and Binary SBOMs offer unique benefits to stakeholders:
Build-time SBOMs: Product Manufacturers
- Improved accuracy of SBOM details because it uses information from the build and/or Continuous Integration/Continuous Deployment (CI/CD) processes.
- Improved risk assessment and mitigation strategies.
- Greater visibility into more components than just source code.
- Compliance with regulatory requirements such as NIST SP 800-161.
Binary SBOMs: Operators of Infrastructure
- Visibility into what’s currently in use when the system is running.
- Details about what components and parts are active or not in use.
- Streamlined vulnerability management processes.
- Compliance with regulatory mandates.
Use Cases for Critical Infrastructure
As part of its Secure by Design initiative, CISA advises the use of SBOMs for software supply chain security:
Publish Software Bills of Materials (SBOMs). Manufacturers should have command of their supply chains. Organizations should build and maintain SBOMs for each product, request data from their suppliers, and make SBOMs available for downstream customers and users. This will help demonstrate their diligence in understanding the components they use in creating their products, their ability to respond to newly identified risks, and can help customers understand how to respond if one of the modules in the supply chain has a newly found vulnerability.
Here are some use cases that demonstrate how SBOMs can be used to help protect different sectors of critical infrastructure:
Water and Utilities: SBOMs play a crucial role in enabling the security and resilience of water and utilities infrastructure. Because water utilities rely on interconnected IT and OT systems, often have legacy infrastructure, are part of an interconnected supply chain, and tend to employ limited cybersecurity resources, they are attractive targets for cyber adversaries.
SBOMs can mitigate some of these risks as part of an overall cybersecurity strategy by identifying and mitigating vulnerabilities in control systems and IoT devices. They can also recognize vulnerabilities across the software supply chain so the water or utility company can proactively protect itself against attack.
IOT/Embedded Systems: The Internet of Things (IOT) and embedded systems enable increased efficiency, productivity, and accuracy in operations. However, limited security measures, rapid increase in devices, insecure communication protocols, weak authentication, and lack of regular updates put IoT devices and embedded systems at higher risk of cyber attacks.
To mitigate these risks, organizations and manufacturers must prioritize cybersecurity throughout the entire lifecycle of IoT and embedded devices, including design, development, deployment, and maintenance. Leveraging SBOMs at each lifecycle stage provides deep visibility of potential vulnerabilities.
Weapons Systems: In the defense sector, weapons systems are interconnected global networks dependent on information technology to provide real-time information, communication, and reaction. The integration of commercial off-the-shelf (COTS) components, lack of secure-by-design practices, and the convergence of cyber and physical threats elevate weapons systems to top targets for nation-state threats.
Employing a strong cybersecurity strategy throughout the entire lifecycle of weapon systems enhances protections against cyber warfare. SBOMs shared among private and public entities across the software supply chain for weapons systems ensure awareness of all potential vulnerabilities and enable proactive actions to increase safety and defenses.
Taking SBOMs to the Next Level
Cyber threat actors are learning as quickly as cybersecurity professionals and are creating more sophisticated vulnerability threats faster and in greater volumes. This evolution requires cybersecurity defenses to evolve exponentially faster.
One way to do this is to integrate cybersecurity practices directly into existing DevOps pipelines to minimize performance impact and ensure complete visibility of components and parts at build time. Utilizing automated tools to extract component information during the build process streamlines the compilation of build-time SBOMs while still gathering vital build-time data.
Conclusion
SBOMs are indispensable tools for safeguarding critical infrastructure against cyber threats. While they may not create security themselves, they offer invaluable insights that arm critical infrastructure organizations with the information necessary to strengthen their cybersecurity posture.
By integrating SBOMs into security frameworks, product manufacturers, developers, and infrastructure operators can enhance visibility, streamline vulnerability management, and mitigate risks effectively.
As cyber threats continue to intensify and cross over to physical vulnerabilities, adopting SBOMs will be a crucial, proactive step in securing our critical infrastructure.
The post Securing Critical Infrastructure: The Role of SBOMs appeared first on RunSafe Security.
]]>The post From Software Bill of Materials to Automated Remediation Across your Software Supply Chain appeared first on RunSafe Security.
]]>From Software Bill of Materials to Automated Remediation Across your Software Supply Chain
The World’s Most Complete SBOM
Addressing Open Source Software Vulnerabilities
The Future of Software Supply Chain Security
Today we released our expanded product offering, complete with the ability to generate a software bill of materials while also automating the remediation of vulnerabilities across your software supply chain – all within your CI build tools, such as GitLab or GitHub.
The World’s Most Complete SBOM
Based on customer feedback, we learned that even though a software bill of materials is a foundational step to understand the risk in your software products – and necessary for sharing with customers what is contained in deliveries to them – not all SBOMs are created equal.
Take compiled code written in C/C++. Whereas most companies derive an SBOM from the software binary, resulting in missing information, RunSafe generates the SBOM during the build process where we have perfect information about what goes into your product.
As a result, whether you need to generate an SBOM, search it for underlying components that may contain vulnerabilities, or need to store and retrieve data for future use, Gremlin creates the most complete SBOM while saving your developers time.
Addressing Open Source Software Vulnerabilities
But that’s not all. Because as much as 60-80% of code in your products come from open source repositories, we learned reducing the attack surface given a complex software supply chain is consuming scarce resources and preventing developers from building new features.
With Gremlin, we incorporated the world’s most efficient and effective automated remediation so developers can ship software with radically reduced attack surface – and no additional work. With RunSafe protections built in, our customers can not only share the most complete SBOM but also highlight how they protected individual components from exploitation.
The Future of Software Supply Chain Security
And we are not done. In the near future, we will roll out additional features for you. We plan to help you gain insights on all the vulnerabilities associated with components in your SBOM, demonstrate how much attack surface you can eliminate with a click of a button, calculate your exposure to any further zero days yet to be discovered, and even alert you when new vulnerabilities are discovered or remediated.
We also believe you will have more ideas on how to enhance the automated management of software supply chain risk without slowing down your developers. Please reach out if you have questions and feel free to start a free trial here. We welcome your feedback.
The post From Software Bill of Materials to Automated Remediation Across your Software Supply Chain appeared first on RunSafe Security.
]]>