How to Get Open Source Risk Ready for Pre-IPO Diligence

Before an IPO, expect four open source questions from underwriters' counsel, your auditors and your own disclosure team: what third party code is in the products you sell, which licenses come with it and whether you meet them, which known exploited vulnerabilities you carry today, and how fast you have fixed past ones. Behind those sits a fifth question that outlives the offering: can you describe the process that produces those answers well enough to support the cybersecurity section of your first annual report under Regulation S-K Item 106? A company that starts about 90 days out can answer all five with evidence instead of promises.

This guide is for the CISO, VP Engineering or general counsel at a US scale-up getting ready to file. It works through what the SEC rule actually requires, the diligence questions that come up in practice, which licenses matter for a SaaS business versus distributed software, how to show fix history rather than a single scan, what belongs in the data room, and who signs off. The first two thirds apply whatever tools you use. Safeguard appears near the end, with maturity labels on every capability.

This post is general information, not legal, securities or investment advice. Materiality, risk factor wording and license interpretation are calls for your securities counsel and your open source counsel.

Key takeaways

• Item 106 is an annual report requirement, not a registration statement one. The SEC chose not to require Item 106 in registration statements, but it reiterated that companies should consider the materiality of cybersecurity risks when preparing registration statement disclosure. Your first Form 10-K after listing carries Item 1C.
• Diligence asks for evidence, not posture: an inventory, a license report, known exploited vulnerabilities with status, and a fix record.
• License risk depends on how you ship. Network copyleft such as AGPL-3.0 reaches SaaS. Strong copyleft such as GPL mostly bites when you distribute: on-premises builds, SDKs, agents, mobile apps and JavaScript sent to the browser.
• Fix history cannot be created after the fact. It only exists from the day you start recording scans, pull requests and exceptions, which is why the plan starts 90 days out.
• The data room gets summaries and policies, not a map for attackers. Keep exploit detail, unpatched internet facing specifics and credentials out.
• Sign off is shared. Engineering owns the inventory and fixes, security owns the vulnerability program, legal owns license interpretation and disclosure, finance owns the disclosure controls that tie it together.
• Safeguard capabilities covered, with labels: SBOM generation and analysis (GA); SCA and vulnerability management with EPSS and KEV (GA); reachability analysis (GA, some language support in Preview per the docs); license compliance with attribution generation (GA); policies, gates and exceptions (GA); products that group projects, the executive dashboard and bulk data export (GA); autonomous remediation (GA, ships switched off with every category set to Manual); Safeguard CLI and MCP server (GA); desktop app; TPRM (GA); fork and patch (GA).

Who asks about open source before an IPO, and why

Three groups reach into your software supply chain on the way to listing, and each wants something slightly different.

Underwriters and their counsel run due diligence so they can stand behind the registration statement. For a software company that usually includes a technology and intellectual property section: what you own, what you license, and whether anything in the code could force you to release proprietary code or stop selling a product. Open source sits squarely in it, and the answers inform the risk factors and the business description.

Your auditors care whether the systems that produce financial data are controlled and whether your disclosure controls work. They rarely ask about a library; they do ask whether change and vulnerability management operate the way your policies say.

The SEC, after you list, expects an annual description of how you assess, identify and manage material cybersecurity risks, and a current report when an incident is determined to be material. That is where the process you build now becomes public language.

Open source is not named anywhere in the SEC rule, but a company that cannot say what is in its software has a hard time describing how it manages the risks that come with it.

What Regulation S-K Item 106 requires, and when it applies after listing

The SEC adopted its cybersecurity disclosure rules in Release No. 33-11216, dated July 26, 2023, effective September 5, 2023. The rule added Item 106 to Regulation S-K, Item 1C to Form 10-K, Item 16K to Form 20-F for foreign private issuers, and Item 1.05 to Form 8-K. Read the release itself rather than summaries; the rule text is short.

The definitions

Item 106(a) defines three terms. A cybersecurity incident is an unauthorized occurrence, or a series of related ones, on or conducted through a registrant's information systems that jeopardizes the confidentiality, integrity or availability of those systems or the information in them. A cybersecurity threat is any potential unauthorized occurrence that may result in those adverse effects. Information systems means electronic information resources owned or used by the registrant, organized for collecting, processing and otherwise handling the registrant's information.

Note the words "owned or used." The software you run includes the open source components inside it, whether you wrote them or not.

Item 106(b): risk management and strategy

Item 106(b)(1) asks a registrant to describe its processes, if any, for assessing, identifying and managing material risks from cybersecurity threats "in sufficient detail for a reasonable investor to understand those processes." The rule then gives a non exclusive list of things to address, as applicable:

1. Whether and how those processes are integrated into the overall risk management system.
2. Whether the registrant engages assessors, consultants, auditors or other third parties in connection with them.
3. Whether the registrant has processes to oversee and identify risks from cybersecurity threats associated with its use of any third party service provider.

Item 106(b)(2) asks whether any risks from cybersecurity threats, including as a result of previous incidents, have materially affected or are reasonably likely to materially affect the registrant, including its business strategy, results of operations or financial condition, and if so how.

The rule does not tell you to run software composition analysis or keep an SBOM. It asks you to describe whatever process you have, and a process you can show working is far easier to describe accurately than one that exists mostly in intent.

Item 106(c): governance

Item 106(c)(1) asks for a description of the board's oversight of risks from cybersecurity threats, including any committee responsible and how it is informed. Item 106(c)(2) asks for management's role: which positions or committees assess and manage these risks and their relevant expertise, how they are informed about and monitor prevention, detection, mitigation and remediation of incidents, and whether they report to the board or a committee.

Note "remediation" in 106(c)(2)(ii). If management says it monitors remediation, someone will ask what that looks like; a fix rate and time to fix by severity, reported on a schedule, is an honest answer.

When it applies after listing

The release sets the compliance dates. All registrants must provide Item 106 disclosure beginning with annual reports for fiscal years ending on or after December 15, 2023. Item 1.05 of Form 8-K applied from December 18, 2023 for registrants other than smaller reporting companies, and smaller reporting companies received an additional 180 days.

For a company going public, that means the first annual report on Form 10-K after listing carries Item 1C, which furnishes the Item 106 information. The release is explicit that the Commission is "not requiring Item 106 disclosures in registration statements," which the SEC's Investor Advisory Committee had recommended. In the same passage the Commission reiterated its 2018 interpretive guidance that companies should consider the materiality of cybersecurity risks and incidents when preparing the disclosure required in registration statements. In practice that guidance shows up in risk factors and the business description of the S-1, which your counsel will draft.

So during the offering, cybersecurity risk appears wherever it is material to the registration statement. After listing, the 8-K incident clock applies, and the first 10-K describes your process and governance in the Item 106 shape. That is the process to build now.

Form 8-K Item 1.05 in one paragraph

Item 1.05 requires disclosure of a cybersecurity incident determined to be material, covering its nature, scope and timing and its impact or reasonably likely impact, within four business days of the materiality determination, with a limited Attorney General delay for national security or public safety. The instructions say a registrant need not disclose specific technical information about its planned response or potential system vulnerabilities in such detail as would impede its response or remediation. Materiality is a legal judgment. Nothing in a scanner makes it for you.

Which open source questions come up in IPO diligence

Request lists differ by firm and by business, but the open source questions tend to fall into five groups. The table shows what is usually asked and what a credible answer looks like.

If you have acquired companies or ship firmware, treat inherited code bases and customer specific forks as their own products in the inventory, or the diligence team will find the gap for you.

Inventory: what is in each product

Inventory is the foundation for every other answer. A license report built from a partial inventory is a partial license report.

On July 29, 2026, CISA and partner agencies published the 2026 Minimum Elements for a Software Bill of Materials, which replaces the 2021 NTIA minimum elements; cite the 2026 document and treat the NTIA one as history. It adds elements including Component License, Component Hash Value and Algorithm, SBOM Tool Name and Version, and SBOM Generation Context, and it renames Supplier Name to Component Producer. CISA says the minimum elements apply to all software, and that some types, such as AI systems and SaaS in cloud environments, may require additional elements.

Two new elements matter for diligence. Component License lets one SBOM feed both the inventory and the license report. SBOM Generation Context records whether the SBOM was produced before, during or after build, which a reviewer comparing it to what ships will want to know.

Known exploited vulnerabilities: the short list that matters

Raw vulnerability counts are a poor diligence answer; every product has findings. The more useful filter is exploitation.

CISA describes its Known Exploited Vulnerabilities catalog as "the authoritative source of vulnerabilities that have been exploited in the wild," and recommends that organizations use it as an input to their prioritization. The federal directive that created the catalog's remediation duties, BOD 22-01 from November 2021, was revoked on June 10, 2026 and superseded by BOD 26-04, "Prioritizing Security Updates Based on Risk." BOD 26-04 binds federal civilian agencies, not private companies, but it shows how a regulator now prioritizes: by asset exposure, KEV status, exploit automation and post exploitation impact, with the shortest timelines and a forensic triage step for the riskiest combinations. Our post on BOD 26-04's four factors covers the model in detail.

FIRST's Exploit Prediction Scoring System adds a forward looking signal: EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days. KEV tells you what attackers already use; EPSS helps rank what is likely next. A diligence answer that says "we fix KEV matches in our shipped products within X days and rank the rest by EPSS and reachability" is far stronger than a severity histogram.

Which licenses create work for a SaaS business, and which for distributed software

License obligations are mostly triggered by what you do with the code. The same component can be harmless in one product and a problem in another. This is the part of diligence where counsel's reading matters most, so treat the categories below as a map for finding the questions, not as answers.

The categories

Most license tools and policies group licenses by obligation:

Use SPDX identifiers throughout. The SPDX License List is the shared vocabulary for license names across SBOM formats and tools, and it is updated regularly (version 3.29.0, dated 2026-09-16, when we checked). Exact identifiers such as GPL-2.0-only versus GPL-2.0-or-later avoid ambiguity that can change the answer.

SaaS: network copyleft is the main exposure

If your product runs on your servers and customers use it through a browser or an API, you generally are not distributing the server side code. The GNU project's own GPL FAQ says the GPL permits anyone to make a modified version and use it without distributing it, and treats running a modified GPL program on a web site as a case of that. The FAQ immediately adds that the situation is different under the GNU Affero GPL.

That difference is section 13 of the AGPL-3.0, "Remote Network Interaction." If you modify an AGPL program, your modified version must prominently offer all users interacting with it remotely through a network an opportunity to receive the Corresponding Source. For a SaaS company, the diligence questions therefore center on:

• Any AGPL component in a service that users interact with, and whether you modified it.
• Source available licenses that restrict offering the software as a service.
• Code that is not as server side as it looks. JavaScript, WebAssembly and other code sent to the user's browser is distributed to that user. The same GPL FAQ entry notes that separate GPL programs delivered to visitors of a site are a different situation from server side use.
• Attribution for anything delivered to the client, which is easy to forget in a web front end.

Distributed software: strong copyleft and attribution

If you ship code that runs on someone else's machine, distribution obligations apply. For an IPO candidate that often includes more than the obvious product:

• On-premises or self hosted editions and appliances.
• SDKs, client libraries and command line tools you publish.
• Agents and collectors installed in customer environments.
• Mobile apps and desktop apps.
• Container images you hand to customers.

Here GPL family licenses can create source code obligations for combined works, LGPL obligations depend on how you link, and even permissive licenses require copyright notices and license text. Missing attribution is a common finding because it is easy to fix and easy to skip.

Label each product in the inventory by how it ships, with one policy for the SaaS backend and a stricter one for anything distributed, so counsel reviews exceptions in context.

Discrepancies and unknowns

Two smaller categories cause outsized work. A license discrepancy is when signals disagree, for example package metadata says MIT while the LICENSE file contains AGPL text. It usually means a packaging error or a relicensing, and it needs a human to resolve. An unknown license is a component with no license, or custom text nobody has classified. No license does not mean free to use; it means you have not been granted rights. Both should be on the list your counsel reviews.

OpenChain as the process reference

If someone asks whether your license program follows a standard, point to OpenChain. Its specification became ISO/IEC 5230:2020 in December 2020 and sets out what a license compliance program needs, such as a written policy, defined roles and a process for reviewing components. You do not need to conform formally before an IPO; mapping your process to it gives reviewers a recognizable structure.

How to show fix history rather than a point-in-time scan

A single scan says what was true on one afternoon. Diligence teams and, later, the SEC description of your process care about whether the program works over time. Fix history is how you prove that, and it has three parts.

1. Repeated measurements, with dates

Run the same scan on the same products on a schedule and on every release, and keep the results. Over 90 days that produces a trend in open findings, KEV matches and new licenses. A falling line with spikes that get fixed is credible. A flat line at zero usually means the scanner was not looking.

2. The fixes themselves

Each closed finding should trace to a change: a pull request that bumped a dependency, a release that shipped it, or a documented decision. Pull requests are better evidence than tickets because they show the code change, the review and the merge time. Time to fix by severity, computed from those records, is the metric most reviewers ask for.

Our earlier post on fix timeline evidence from real tickets for diligence goes deeper on how to build that record from your existing systems.

3. Exceptions with owners and expiry dates

Not everything gets fixed. A credible program records each exception with a named approver, a business justification and an expiry date, and re-evaluates it at expiry. Expired entries nobody revisited are a finding in their own right.

The honest limit

History only exists from when you started recording it. Start 90 days before the data room opens and you have a quarter of trend, enough to show the program is real. Start a year out and you have a much better story for the first 10-K.

What belongs in the data room, and what should stay out

Many people will read the data room, and it may be retained. Put in enough to answer the questions, and keep out anything that would help an attacker.

Put in

• Your written open source policy and license policy, with the date adopted.
• A summary inventory: products, release versions, SBOM format and generation date, and component counts by product.
• SBOMs for each product, if requested, or an offer to provide them in a controlled session.
• A license report by category, the list of flagged components with the decision for each, and your attribution notices.
• A KEV status summary: matches by product, fixed, in progress with target dates, and accepted with justification.
• Fix history: trend charts, time to fix by severity, and a sample of fix pull requests.
• The exception register with approvers and expiry dates.
• Org chart for security and engineering ownership, and examples of management and board reporting.

Keep out, or share only in a controlled session

• Exploit detail or proof of concept code for anything unfixed.
• Specifics of unpatched, internet facing vulnerabilities, such as hostnames, ports and affected endpoints.
• Credentials, tokens, keys and configuration files of any kind.
• Full source code. If a reviewer needs code access, arrange a supervised review rather than a copy.
• Raw scanner exports with thousands of unreviewed findings. Provide reviewed summaries and offer detail on request.
• Legal analysis of specific license questions. Talk to counsel about how their advice should be shared, and whether privilege considerations apply.

The SEC rule itself takes a similar line on technical detail for incident disclosure, saying a registrant need not disclose potential system vulnerabilities in such detail as would impede its response or remediation. The same instinct applies to a data room.

Who signs off: security, legal, engineering, finance

After listing, these meet in the disclosure committee. A security program that cannot quickly tell that committee which products a new exploited vulnerability touches is a disclosure controls problem, not just a security one.

A 90 day readiness plan

This plan assumes you have source control, CI and someone who can own each workstream. Adjust the timing; keep the order.

Days 1 to 30: inventory and policy

1. List every product you sell, how each ships (SaaS, on-premises, SDK, agent, mobile, container) and which repositories and images make it.
2. Generate an SBOM for each, from source and from built images where you can, and record the generation context.
3. Write or update your license policy: allowed, denied and review required lists, with stricter rules for distributed products.
4. Write a one page vulnerability policy: how you prioritize (KEV, EPSS, reachability, severity), target fix windows, and how exceptions are approved.
5. Name owners for each product and for each workstream.

Days 31 to 60: triage and fix

1. Run license classification across every product. Send flagged components, discrepancies and unknowns to counsel with context about how each product ships.
2. Pull the KEV matches across all products. Fix what is in shipped code first, then rank the rest by reachability and EPSS.
3. Turn on scheduled scans and release scans so the trend starts accumulating.
4. Put gates in CI for denied licenses and for new KEV matches, so the numbers stop growing while you fix the backlog.
5. Record every exception with an approver and an expiry date.

Days 61 to 90: evidence and narrative

1. Generate attribution notices for distributed products and ship them.
2. Assemble the data room set listed above.
3. Produce trend charts and time to fix by severity from the 60 days of history you now have.
4. Draft the process description your counsel will use, in plain language, mapped to the Item 106(b) and (c) topics: process, integration with enterprise risk management, third parties involved, management roles and expertise, and board reporting.
5. Have a recent real example ready for the question "show me how a new KEV match gets handled."

How Safeguard does this job, step by step

This section shows how Safeguard covers the inventory, license, vulnerability and fix history parts, using the flows in its docs.

Step 1: Connect repositories and images, and generate SBOMs

SBOM generation and analysis is GA. In the web app, open Integrations from the sidebar. The Add Project/Product tab lists source code integrations (GitHub, GitLab, Bitbucket and generic Git), container image sources (Amazon ECR, Docker Hub, GCP and any OCI registry) and uploads, including package manifests and CSAF or VEX files. For each repository you choose the branch or tag, project name and version, then click Connect.

Generation options include Include Dev Dependencies and Deep Analysis, which uses Griffin AI.

You can also scan from a developer machine or CI runner with the Safeguard CLI (GA). The docs show:

# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash

# Open the terminal, then type /login and /scan .
safeguard

# Or scan from the command line, writing results under ./output
safeguard scan --dir .

Per the docs, a scan from the interactive terminal while signed in uploads the SBOM and findings to the platform, and your source never leaves the machine. SBOMs are produced in SPDX and CycloneDX.

Step 2: Turn on continuous and release scanning so history accumulates

Safeguard's docs say it performs daily continuous scanning of all projects to detect newly disclosed vulnerabilities. You can add triggers On Push for monitored branches, Scheduled at a daily, weekly or custom interval, and On Release when new tags are created. Release scans are the ones that build the "what shipped, and what was in it" record diligence asks for. Turn them on in week one; the history starts then.

Step 3: Group projects into products

In Safeguard, a Product groups multiple projects so you see combined risk across a release train or business unit. Group by what you sell, for example the SaaS platform, the on-premises edition and the mobile apps, so diligence answers come out per product without spreadsheet work.

Step 4: Write the license policy as code

License compliance is GA. Safeguard reads licenses from package metadata, SPDX identifiers, LICENSE and NOTICE file text, source headers and container layers, and raises a license discrepancy finding when those signals disagree. Each license gets an obligation category; the docs class SSPL-1.0 with AGPL-3.0 as network copyleft, high risk for SaaS.

The docs show a policy in YAML, scoped by context so distributed and server builds can differ:

apiVersion: safeguard.sh/v1
kind: LicensePolicy
metadata:
  name: default
spec:
  allow:
    - MIT
    - BSD-2-Clause
    - BSD-3-Clause
    - Apache-2.0
    - ISC
    - MPL-2.0
  deny:
    - GPL-3.0-or-later
    - AGPL-3.0-or-later
    - SSPL-1.0
  require_review:
    - GPL-2.0-only
    - LGPL-3.0-or-later
    - "Custom/*"
  context_overrides:
    - apply_to: { env: sdk }
      deny:
        - LGPL-3.0-or-later   # LGPL tricky in SDK distribution
    - apply_to: { env: server }
      allow:
        - LGPL-3.0-or-later   # fine for a service binary

Treat that as the docs' example, not a recommendation; counsel sets the lists. In the app, license policies live under Settings › License Policies, where you click + New Policy, configure allowed and blocked licenses, set the scope to organization or project, and save. Rules can be allowlist, blocklist or review list.

Safeguard parses full SPDX expressions, including OR, AND and WITH exceptions.

Step 5: Review flagged licenses and generate attribution

Open a project and go to the Suppliers & Licenses tab to see license distribution, compliance status (Compliant, Review Needed, Violation or Unknown) and each component's SPDX identifier, license text, obligations and attribution requirements. That view is what you send to counsel, with your product labels attached so they know how each component ships.

For attribution, the docs describe Export › Attribution Notice with TXT, HTML or Markdown output and a customizable template. For redistributed artifacts, the license compliance docs say Safeguard generates a NOTICE or THIRD-PARTY-NOTICES.txt file, a licenses directory with copies of required license texts, and a machine readable SPDX document for each release. The docs also note there is no CLI command for generating these yet, and none for license listing or policy evaluation; safeguard scan writes a license.json with the licenses it found alongside its other results.

Temporary license exceptions use the same workflow as vulnerability exceptions: a named approver, an expiry date and a documented business justification, with automatic re-evaluation at expiry.

Step 6: Filter vulnerabilities to KEV, then rank by exploitability and reachability

SCA and vulnerability management are GA. Safeguard detects CVEs from sources including NVD, GitHub advisories, OSV and CISA KEV, with EPSS and KEV status on findings. Reachability analysis is GA and folds reachability, EPSS, KEV and business context into one priority. Safeguard's docs say this cuts findings by roughly 60 to 80%; treat that as Safeguard's stated figure, not a guaranteed result for your code.

KEV matches per product, with status, plus your fix window policy, answer the known exploited vulnerabilities question directly.

Step 7: Gate new risk while you fix the backlog

Policies, gates and guardrails are GA. The license compliance docs describe enforcement at three points: CI builds fail if a denied license appears in the dependency tree, images with denied licenses cannot deploy at admission, and a new direct dependency with a deny listed license gets a blocking check at pull request time. Findings show the transitive path. The same policy engine applies to vulnerability rules, so you can block new KEV matches at the gate while the existing ones are worked down.

Step 8: Open fix pull requests, and keep the record

Autonomous remediation is GA, and it ships switched off with every category set to Manual. When you enable it, Griffin opens tested, policy gated pull requests that move a vulnerable dependency to a fixed version, for one repository or in bulk with one pull request per repository, with breaking change detection. Each merged pull request is the fix record diligence wants: the change, the review and the merge time. Start with Manual approval for every category and widen it only when your team is comfortable.

Step 9: Read the dashboard and export the evidence

The executive dashboard and bulk data export are GA. The dashboard docs describe a top risks list that includes actively exploited CVEs and aging vulnerabilities, trend charts with mean time to remediation, a fix rate panel with vulnerabilities fixed per week and time to fix by severity, and license compliance trends. Every number drills through to the underlying results.

The dashboard exports as a PDF, and scheduled weekly or monthly reports give management and the board a regular view, which supports the Item 106(c) story. License manifests export in Excel, CSV, SPDX and CycloneDX, and bulk export covers CSV, Excel, PDF, JSON and more. Put reviewed summaries in the data room; keep raw exports for controlled sessions.

Step 10: Answer follow up questions from an assistant

Follow up calls bring questions nobody prepared for. Safeguard's MCP server (GA) lets an assistant such as Claude query your Safeguard data, read only, with the tools you allow, for example listing products, filtering vulnerabilities by severity or exploit status, and pulling findings for a project. Safeguard is listed in the Claude connector directory as a community connector. Answers from an assistant are a starting point for your team to verify, not data room content in themselves.

Requirement, Safeguard, and what you still own

What Safeguard cannot answer for counsel

• Materiality. Whether a vulnerability, incident or license problem is material to investors is a judgment for management and counsel. Safeguard shows what is there; it does not decide what matters to a reasonable investor.
• Legal interpretation of a license. Safeguard classifies licenses and flags policy violations. Whether a specific use of a GPL or AGPL component triggers an obligation is a question for counsel.
• Your incident history. Prior incidents and notifications come from your incident records, legal files and insurers, not from supply chain data.
• Risk factor and Item 1C wording. Safeguard can supply accurate facts about your process; writing the disclosure is counsel's job.

What Safeguard does not do

• It does not give legal, securities or investment advice. License findings need legal review.
• It only sees what you connect. Repositories, images and uploads you have not connected are outside the inventory. Code in vendor appliances, hosted services you consume, and firmware you do not build is not covered unless you have an SBOM for it.
• It cannot create history retroactively. Trends, time to fix and fix rate start when scanning starts. Last year's numbers cannot be reconstructed.
• Some license and export work has no CLI path yet. The docs state there is no CLI command for license listing, reports, policy evaluation or attribution generation; use the web app for those.
• Autonomous fixes are off until you turn them on. Remediation ships with every category set to Manual. Pull requests need your review and merge, and some upgrades will need engineering work.
• Some adjacent capabilities are generally available. The desktop app, Trust Center and fork and patch are generally available; check what your plan includes before building a plan around them.

Common mistakes

1. Starting with a one-off audit two weeks before the data room opens. You get a snapshot and no history, and every finding looks like a surprise. Start scanning at least a quarter ahead.
2. Inventorying the main product and forgetting the rest. SDKs, agents, mobile apps, on-premises editions and acquired code bases are where strong copyleft and stale dependencies hide.
3. Treating SaaS as immune to license risk. AGPL and restrictive source available licenses reach hosted services, and browser delivered code is distributed.
4. Dumping raw scanner output into the data room. Provide reviewed summaries and the policy behind them.
5. Reporting severity counts instead of KEV status. The question is what you carry that attackers already use, and how fast you fix it.
6. Letting the process description outrun the process. Item 1C in the first 10-K should describe what actually operates.
7. Citing superseded documents. Use CISA's 2026 SBOM minimum elements and BOD 26-04, and mention the 2021 NTIA elements and BOD 22-01 only as history.

FAQ

What open source questions come up in IPO due diligence?

Expect requests for a component inventory per product, a license report with any copyleft or unknown licenses flagged, a list of known exploited vulnerabilities and their status, evidence of how quickly you fix vulnerabilities, and a description of who owns the program and what management and the board see.

Does Regulation S-K Item 106 apply to an S-1 registration statement?

The SEC's adopting release says the Commission is not requiring Item 106 disclosure in registration statements. It reiterated its 2018 guidance that companies should consider the materiality of cybersecurity risks and incidents when preparing registration statement disclosure. Item 106 information appears in Item 1C of Form 10-K. Ask your securities counsel how this applies to your filing.

When does a newly public company first have to file Item 106 disclosure?

Item 106 applies to annual reports for fiscal years ending on or after December 15, 2023, so in practice it starts with the first Form 10-K you file after listing. Form 8-K Item 1.05 incident reporting applies once you are a reporting company, within four business days of determining an incident is material.

Is AGPL a problem for a SaaS company?

It can be. Section 13 of the AGPL-3.0 requires a modified version to offer users interacting with it over a network an opportunity to receive its Corresponding Source. Whether a given use triggers that depends on facts such as modification and how users interact, so flag AGPL components for counsel.

Is GPL code a problem if we only run it on our servers?

The GNU GPL FAQ says the GPL permits running a modified version without distributing it, including on a web site. The picture changes if you distribute the code, for example in an on-premises edition, an agent, a mobile app or JavaScript sent to the browser. Counsel should review each case.

Should we put SBOMs in the IPO data room?

Provide a summary inventory by product and supply full SBOMs on request or in a controlled session, since they are detailed maps of your software.

How do we prove our vulnerability fix history to diligence teams?

Show repeated scans over time, time to fix by severity calculated from the pull requests that did the fixing, and an exception register with approvers and expiry dates. History only exists from when you start recording, so start at least a quarter before the data room opens.

What SBOM standard should we use for IPO readiness?

Produce SPDX or CycloneDX and check them against CISA's 2026 Minimum Elements for a Software Bill of Materials, which replaced the 2021 NTIA minimum elements and add a Component License element.

Closing the gap your fix history measures

Diligence reviewers look hardest at the gap between a known exploited vulnerability appearing and the fix shipping in your products, because that gap is what your fix history measures. These are the ways Safeguard helps close it, including the cases where no upstream fix exists yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The desktop app demo shows a real session in the Safeguard desktop app: the CLI session appears in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with an upgrade done and tests passing. During readiness, the same flow applies to working down KEV matches in a repository, with every change approved by an engineer, which leaves a clear record of each fix.

Click through it at your own pace, or open it full screen.

The Claude demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. For diligence, that is how a security lead could answer a follow up question, such as which products carry a given component, from the same data the dashboard shows, then verify before sending.

Click through it at your own pace, or open it full screen.

The CLI demo shows a real terminal session: ask it to fix a lodash CVE, approve any command that changes something as it edits package.json to lodash 4.17.21 and runs npm install and npm test, with nothing pushed, then /permissions, /model and /scan. That /scan . step starts your inventory and history from a developer machine.

Click through it at your own pace, or open it full screen.

To try it on your own code, download the apps and CLI at safeguard.sh/download and read the setup guides at docs.safeguard.sh.

For more background, see our posts on SEC cybersecurity disclosure rules for public companies, copyleft risk in acquisitions and GPL linking, what an open source audit is and how to read an open source audit report.

Quick check

Sources

• SEC Release No. 33-11216: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure (PDF)
• CISA: 2026 Minimum Elements for a Software Bill of Materials (PDF)
• NTIA: The Minimum Elements for a Software Bill of Materials (2021, superseded)
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: BOD 22-01 (revoked)
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System (EPSS)
• SPDX License List
• OpenChain: ISO/IEC 5230 License Compliance
• GNU Affero General Public License v3.0
• GNU: Frequently Asked Questions about the GNU Licenses
• Safeguard docs: License Compliance
• Safeguard docs: Suppliers & Licenses
• Safeguard docs: ESSCM Dashboard
• Safeguard docs: Generate SBOM

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.