Article
Card image cap for article

Vulnerability Monitoring and Minimizing the Attack Surface for Software

Cybersecurity

7/20/2025

Introduction

In today’s interconnected software landscape, modern web applications are built on complex stacks, combining frameworks like .NET with a host of third-party libraries such as jQuery, Bootstrap, and DataTables.

While these tools accelerate development and innovation, they also introduce hidden risks: vulnerabilities that can be exploited if left unchecked.

This article explores why proactive vulnerability monitoring is essential, the critical role of SBOMs (Software Bill of Materials). It also shows how tools like CycloneDX and Dependency-Track help organizations, especially in regulated sectors like medical devices, to strengthen their software security.

Theoretical Background: Why Monitor Vulnerabilities?

The Expanding Attack Surface with Software

Every dependency, whether a core .NET package or a front-end library, can be a potential entry point for malicious actors. Vulnerabilities in these components are frequent targets.

Open-Source Software

In the open-source world, many critical projects are maintained by small, highly motivated teams or even single individuals, which can limit the capacity for rapid patching, long-term maintenance, and thorough security review. The Heartbleed vulnerability in OpenSSL is a well-known example - an issue in a widely used cryptographic library maintained by a very small group that exposed millions of systems to potential data leaks

Closed-Source Software

At the same time, closed-source components introduce their own risks, as their inner workings are opaque, vulnerability information is often tightly controlled, and organizations must rely on vendors for timely disclosure and fixes. As software supply chains grow more complex, these factors combine to expand the attack surface, making continuous monitoring and prompt remediation essential.

Early Detection, Lower Risk
  • Early vulnerability scanning helps developers catch security weaknesses before deployment, reducing remediation costs and the risk of exploitation in production
  • Regular monitoring ensures that, as new vulnerabilities are disclosed, development teams can respond quickly and proactively, rather than reacting after an incident occurs
Regulatory and Business Drivers
  • Many industries, including finance and healthcare, are now required to demonstrate active vulnerability management and software transparency for compliance (PCI-DSS v4.0, and FDA, respectively)
  • Customers and partners increasingly expect proof that the software vendor knows, and monitors what’s inside the software.

Practical Perspective: the Role of SBOMs

What is an SBOM?

A Software Bill of Materials (SBOM) is an inventory of all software components, including third-party and open-source libraries, used in an application. It’s like a parts list for software, providing transparency into what is released into the market.

Why SBOMs are Essential

If the development team does not know the software components they have implemented in their product and their version, they can hardly make any structured attempt to protect the software base. That's why SBOMs are so important.

  • Visibility: SBOMs (preferably in machine-readable form) make it possible to quickly identify if a product is affected by a newly discovered vulnerability
  • Compliance: regulatory bodies (like the FDA) now require SBOMs for medical device submissions, supporting cybersecurity risk management across the product lifecycle
  • Incident Response: when a new vulnerability is disclosed, an SBOM enables teams to quickly identify affected components and take immediate action.
  • Trust and Transparency: SBOMs foster trust with customers, partners, Healthcare Delivery Organizations, and regulators by demonstrating proactive risk management
Common Vulnerabilities and Exposures (CVE) system

Utilizing the Common Vulnerabilities and Exposures (CVE) system is essential for effective vulnerability monitoring. The CVE provides a universal, standardized repository of publicly known security vulnerabilities, enabling organizations to identify, assess, and respond to software risks efficiently.

By integrating CVE tracking into the vulnerability monitoring process, software providers ensure no critical threats are overlooked. Actions to mitigate these risks are prioritized based on real-world data.

In finance, and in the medical device industry, this is an important element to show regulatory compliance is supported. In a fast-evolving threat environment, leveraging the CVE empowers organizations to maintain robust security postures and respond proactively to emerging risks.

MITRE CVE Database

The CVE database of MITRE [1] is the official and most trusted source for all CVE identifiers and basic vulnerability information.

  • Key features: authoritative CVE assignments, unique IDs, and links to additional references
  • Best for: baseline CVE tracking, software inventory mapping
National Vulnerability Database (NVD)

The National Vulnerability Database NVD [2] is a U.S. government repository that enriches CVE data with the Common Vulnerability Scoring System (CVSS), impact metrics, and remediation information.

  • Key features: severity ratings, exploitability metrics, extensive metadata, and machine-readable feeds
  • Best for: detailed risk assessment, compliance, and automation

The Forum of Incident Response and Security Teams (FIRST) provides online calculators to determine the CVSS score [3].

Formats to Support Machine Readability and Automation

Interoperability across manufacturers, regulators, and customers is enabled by standardizing metadata for software components. This is achieved using SBOM and tagging standards such as SPDX (Software Package Data Exchange), CycloneDX, and SWID (Software Identification) tags.

CycloneDX for SBOM generation
  • Security-Focused: CycloneDX [4] is a leading SBOM standard designed specifically for security use cases, embedding vulnerability, license, and dependency data
  • Automation: it integrates seamlessly with build pipelines, enabling automated, repeatable SBOM generation for both .NET (NuGet) and npm-managed JavaScript libraries
  • Regulatory Alignment: CycloneDX meets regulatory requirements, including those set by the NTIA, FDA, and the EU’s NIS2 directive
  • Comprehensive Coverage: generates inventories that include both backend and frontend dependencies
Dependency-Track for Vulnerability Monitoring
  • Continuous Analysis: Dependency-Track [5] consumes SBOMs and continuously scans for vulnerabilities using multiple intelligence sources (NVD, GitHub, Snyk, etc.)
  • Severity and CVE mapping: it lists all detected vulnerabilities, their severity (e.g., CVSS scores), and associated CVEs for every component, whether it’s a .NET package or a JavaScript library
  • Risk Prioritization: Dependency-Track enables teams to focus on the most critical issues and document remediation steps for compliance and audit trails
  • Supply Chain Security: it tracks not only direct dependencies, but also transitive ones, providing a full-stack view of risk

Note: Dependency-Track tends to generate a high number of false positives, which require manual analysis. For embedded software, tools such as Vigiles [6] may provide more accurate results.

Workflow for Maintaining Software Security for Dependencies

In a regulated industry such as finance or healthcare, the following process is recommended to follow:

  1. Inventory and Update Dependencies: regularly maintain and update .NET (NuGet) and npm packages within the IDE (e.g., Visual Studio) to address known vulnerabilities and ensure all third-party components are tracked.
  2. Generate or update SBOMs: use CycloneDX to generate or refresh SBOMs for both .NET and JavaScript dependencies, capturing component versions and metadata for transparency.
  3. Upload to Dependency-Track: import SBOMs into Dependency-Track to automate vulnerability identification and ongoing monitoring.
  4. Evaluate findings: follow a predefined analysis scheme to assess vulnerabilities for exploitability and severity based on CVE and CVSS information
  5. Prioritize and document actions: rank findings according to a risk assessment framework tailored to your product and user environment, and document the planned response for each.
  6. Implement corrective actions: execute remediation decisions - such as patching, updating, mitigating, or accepting residual risk - based on the documented risk analysis.

Note: Some software components may appear vulnerable even though the reported issues are not relevant in practice. For example, the affected functionality might not be used, or compiler and build-time options could disable the specific code paths required to exploit the vulnerability.

Pre-Update to Post-Update Situation in an ASP.NET Core Web Application

On my website https://dirkmueller8.com/ I tested the SBOM generation and software update procedure. After updating the libraries and the framework from .NET 8 to .NET 9, the situation improved substantially. I was able to close four of the vulnerabilities, compared to the title image with 5 vulnerabilities with High severity (see top figure).

Regarding the remaining vulnerability, I checked if System.text.json version 9.0.7 is indeed the latest version, as there is still the vulnerability CVE-2024-43485 with High severity.

My research revealed that System.Text.Json 9.0.7 is currently the latest stable release available in NuGet. However, there are preview versions for .NET 9 (such as 9.0.0-preview.7), but these are not considered stable releases for production use. So, that is perhaps not a good choice. However, it is advisable to perform research for judging if the benefit of a stable software outweighs the risk associated with not upgrading the software.

CVE-2024-43485: High-Severity Vulnerability

CVE-2024-43485 is a high-severity vulnerability affecting System.Text.Json, specifically versions in the 6.0.x and 8.0.x ranges. The vulnerability allows for a Denial of Service (DoS) attack via algorithmic complexity when deserializing JSON into objects with an [ExtensionData] property. The issue is classified under CWE-407 (Inefficient Algorithmic Complexity), with a CVSS score of 7.5 (High). There is currently no explicit mention in public advisories that 9.0.7 is affected, but it is advised to assume risk if the code uses [ExtensionData] until Microsoft confirms otherwise.

Even when it might be a false positive, the best workaround is to avoid using the [ExtensionData] property in the models to mitigate risk. These are the type of decisions the developers and risk managers must take, by comparing the benefit of that functionality vs. the risk involved.

Vulnerability Monitoring for Medical Device Manufacturers in the US

Introduction and Background

An SBOM is a compulsory component of all FDA submissions for cyber devices. The FDA defines a "cyber device" as a medical device containing possibly vulnerable software and being capable of internet connectivity [7].

The SBOM must be machine-readable and include every commercial, open-source, Software of Unknown Provenance (SOUP), and off-the-shelf (OTS) software component incorporated into the device, along with their dependencies.

This requirement applies to all premarket submissions, including 510(k), De Novo, PMA, PDP, and HDE. This is outlined in the FDA’s latest guidance on device cybersecurity issued in June 2025 [7].

The process of generating and utilizing an SBOM involves more than simply producing a list of software components. Manufacturers must establish robust procedures to ensure SBOMs are accurate, complete, and regularly updated throughout the product lifecycle. The FDA expects manufacturers to integrate SBOM management into their Secure Product Development Framework (SPDF). This enables ongoing vulnerability identification, supply chain risk analysis, incident response planning, and postmarket update processes.

Historically, early SBOM draft standards were available as far back as 2014, but a surge in high-profile cyberattacks on healthcare - most notably the WannaCry ransomware attack - highlighted the urgent need for visibility into device software composition. These incidents led the FDA to require that SBOMs be included and maintained with submissions, allowing healthcare delivery organizations and regulators to verify device software risks and respond effectively to vulnerabilities.

Initially, many manufacturers believed submitting a simple component list would be adequate for healthcare customers. However, the FDA clarified that the true purpose of an SBOM is for manufacturers to have a complete, structured inventory of the software in their products. This was not just for the purpose of disclosure, but to enable effective risk control and prompt response to emerging threats. This systematic approach facilitates coordination between manufacturers, healthcare organizations, and patients, even when devices are sold directly to end-users.

Manufacturers must establish systems for tracking software components in legacy devices as well as upcoming products. SBOMs must be kept up to date, reflecting all modifications, software updates, and postmarket security measures. Only by maintaining accurate SBOMs, and integrating them into cybersecurity management plans can manufacturers fulfill FDA requirements and ensure ongoing patient safety in a rapidly evolving threat landscape.

Process of Vulnerability Monitoring and Risk Assessment

Baseline Attributes of an SBOM

In an SBOM, baseline attributes encompass two types of data:

1.) Minimum required data elements needed to identify and describe each software component within the product

These attributes were formally defined by the U.S. National Telecommunications and Information Administration (NTIA) and later reinforced by guidance from Cybersecurity and Infrastructure Security Agency (CISA) to ensure software supply-chain transparency.

The minimum attributes are:

  • supplier name of software component
  • name of software component
  • version of software component
  • unique identifier such as Package URL, CPE or a SWID tag
  • dependency relationship, how the component is related to others
  • author of SBOM
  • timestamp

2.) Supplementary data elements such as

  • hashes of the software components
  • level of support etc.
  • end of date of support

The supplementary information might not always be possible to attain. This should be documented for traceability purposes.

Common Platform Enumeration (CPE)

The Common Platform Enumeration (CPE) in an SBOM is a standardized and structured identifier used to uniquely identify and classify software applications, operating systems, and hardware platforms.

CPEs, maintained by the National Institute of Standards and Technology (NIST), provide a formal naming scheme that enables precise and unambiguous identification of components across information technology environments. By adhering to this naming convention, CPEs facilitate consistent cross-referencing of software components among security tools, regulatory frameworks, and vulnerability databases. Thereby, it supports automated vulnerability detection and supply chain risk management.

Special Considerations for Software by Medical Device Manufacturers

There is a significant difference between building SBOMs for custom web applications (like the one presented in the first section of this article) and for medical device software. Most traditional software development today focuses on web-based applications, often deployed on cloud platforms like Azure or AWS, written in languages such as Python or C#, and supported by automated SBOM generation tools and static analysis libraries. These solutions are relatively straightforward when the deployment environment is well-defined.

In contrast, some medical devices run software that is tightly coupled to specialized hardware, with multiple layers, including operating systems and packaged third-party applications. For instance, a medical device might operate on Windows and include utility programs like Adobe Reader. In these cases, SBOMs typically contain 20 to 200 distinct components, reflecting operating system elements, bundled applications, and device-specific libraries.

In embedded software running on bare metal the number of software components can be much smaller, typically 5-20 components.

A key lesson from the WannaCry ransomware attack was that knowing the precise version and patch level of the operating system is crucial for effective vulnerability management. The FDA mandates that SBOMs for medical devices must include complete and accurate details of all software components. This includes the detailed information listed above. Thereby, device manufacturers, regulators, and healthcare providers can respond rapidly to emerging threats and ensure patient safety, data confidentiality and integrity, together with the availability of the device.

As medical devices are increasingly integrated into networked environments, it is essential to minimize the risk of a device being exploited as an entry point to attack other systems on the same network (FDA calls this "multi-patient harm view").

Assessment Process for Vulnerabilities and Threats

It is common for a vulnerability scan to detect thousands of issues in medical device software. Because of the sheer size of the list, manufacturers must implement a systematic approach to filter, analyze, and prioritize vulnerabilities for remediation.

FDA regulations do not specify a universal CVSS threshold for required action, so manufacturers are expected to establish and document their own vulnerability management policy. This policy must outline how vulnerabilities are classified and prioritized, as well as the criteria to determine which findings can be safely discarded and which require immediate attention.

Effective prioritization typically follows three essential criteria:

  1. CVSS severity score to gauge the potential impact of the vulnerability
  2. Exploitability, including whether the vulnerability is being actively exploited (such as through Exploit Prediction Scoring System or CISA KEV repositories)
  3. Risk assessment specific to the device and operating environment, focusing on patient safety, data integrity, and avoidance of operational disruption

Critical vulnerabilities, especially those with a high likelihood of exploitation and significant safety or data impact, should be addressed first. All findings, decisions, and remediation actions must be meticulously recorded for regulatory and audit purposes. A patch and update process is to be tied to this process.

If a single patch resolves multiple vulnerabilities, manufacturers should note this efficiency as part of their risk mitigation plan. Finally, it is crucial to communicate identified risks and mitigations promptly to customers, end-users, and regulatory authorities as required by FDA postmarket cybersecurity policy.

Conclusion

Vulnerability monitoring is not optional. It is a core responsibility for any development team, especially when using frameworks and third-party libraries. SBOMs provide the transparency needed to manage this risk, and tools like CycloneDX and Dependency-Track make the process actionable, auditable, and aligned with modern compliance standards.

For industries like medical devices, this approach is not just best practice, it is a regulatory necessity. In Europe, the SBOM is not explicitly required, but in the US it is compulsory to include SBOM and a vulnerability monitoring into the submission documentation to the FDA, whenever cyber devices under the FD&C Act Section 542B are concerned.

References

[1] MITRE Corporation Common Vulnerability and Exposures (CVE), URL: https://cve.mitre.org/ redirected to https://www.cve.org/

[2] NIST National Vulnerability Database (NVD) URL: https://nvd.nist.gov/vuln-metrics/cvss

[3] Forum of Incident Response and Security Teams (FIRST), URL: https://www.first.org/cvss/

[4] CycloneDX from OWASP Foundation, URL: https://cyclonedx.org/

[5] Dependency track, by OWASP Foundation, URL: https://dependencytrack.org/

[6] Vigiles Software, URL: https://linuxlink.timesys.com/docs/vigiles-vulnerability-monitoring-and-management-user-guide

[7] Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, FDA Guidance, June 2025, URL: https://www.fda.gov/files/guidance%20documents/published/GUI00001825-final-PremarketCybersecurity-2025.pdf

Go back