No AppSec Team, IPO on the Calendar: The First 90 Days

If your company is heading toward an IPO and nobody owns application security, the first 90 days are about four things: one named owner, a complete inventory of what you build and ship, a written rule for which risk blocks a release, and evidence that the rule runs every day. You do not need a five person AppSec team to get there. You need a process that engineering already follows, a backlog ranked by real exploitability, and records that an auditor, an underwriter's counsel and your future audit committee can all read without a translator.

This guide is written for the VP of Engineering or CTO who has just been told that application security is theirs until the first security hire lands. It works with whatever tools you have. Safeguard comes in near the end, and only where it saves you time.

Key takeaways

• The SEC's 2023 cybersecurity rule adds Item 106 to Regulation S-K and Item 1.05 to Form 8-K. Once you are public, you describe your processes for assessing, identifying and managing material cyber risk, and how the board and management oversee them. Build the process now so you are describing something real later.
• A SOC 2 Type II report tests whether controls operated over a period. If your change management and vulnerability management only exist on paper, the observation window will show it.
• In the first 30 days, name one accountable owner, inventory every repository, artifact and third party component, and freeze the rules for what blocks a release.
• In days 31 to 60, put gates in CI that block only what you have agreed is unacceptable, rank the backlog by known exploitation and reachability, and set fix timelines you can actually meet.
• In days 61 to 90, turn the daily work into evidence: a metrics page for the board, a risk register entry for application security, and a hiring plan for the first AppSec lead.
• Safeguard capabilities used in this guide, each GA: SBOM generation and analysis (GA), SCA with deep transitive dependency scanning (GA), vulnerability management with EPSS and KEV enrichment (GA), reachability analysis and prioritisation (GA), policies, gates and exceptions (GA), license compliance (GA), SAST and DAST (GA), autonomous remediation (GA, ships off with every category set to Manual), in-app search (GA), the compliance and GRC suite (GA), Trust Center (GA), and the CLI with its local runner (GA).
• This is not legal or audit advice. Your securities counsel decides what goes in a filing; your auditor decides what passes.

The situation

The board approved an IPO readiness plan. Bankers are talking about a window twelve to eighteen months out. Finance has a new controller and an internal audit consultant. Legal is drafting a disclosure committee charter. And in the readiness workstream list, a line item reads "Application security program: owner TBD."

That line lands on engineering, because engineering owns the code, the pipelines and the cloud accounts. Nobody on your team has "security" in their title. You have a cloud security person who also runs the IAM roles, a platform team that owns CI, and maybe a contractor who ran a penetration test last year. There is a SOC 2 Type I report from the Series B days, and the Type II observation window opens next quarter.

Here is what a bad week looks like if nothing changes:

• A large prospect's security questionnaire asks how you track open source components, what your fix timelines are and who approves exceptions. Three engineers write three different answers.
• A widely exploited vulnerability hits a popular library. Someone asks "are we affected?" and the honest answer takes four days because nobody knows which services pull it in.
• The SOC 2 auditor samples twenty five production changes and asks for evidence that each passed the security checks you described in your system description. Eleven skipped them because a pipeline step was set to "continue on error."
• Underwriters' counsel sends a diligence request list with a cyber section: policies, incident history, third party risk, vulnerability management, board reporting. You have a wiki page from 2023.

None of these require a mature AppSec team to fix. All of them require that somebody owns the problem, that the process runs every day, and that it leaves a record.

What the rules behind this actually ask

Read the primary texts yourself, or have counsel walk you through them. Summaries tend to drift. The points below are what matters for an engineering leader planning the next 90 days.

The SEC rule: Item 106 and Form 8-K Item 1.05

The SEC's final rule "Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure" was published in the Federal Register on 4 August 2023 (88 FR 51896) and took effect on 5 September 2023. It added Item 106 to Regulation S-K, a new Item 1C to Form 10-K that calls for the Item 106 information, and Item 1.05 to Form 8-K.

Here is what the adopted regulatory text says, in plain terms.

Item 106(b), risk management and strategy. Paragraph (b)(1) asks the 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." It then gives a non-exclusive list to address where it applies:

• (i) whether and how those processes are integrated into the overall risk management system;
• (ii) whether the company engages assessors, consultants, auditors or other third parties for them;
• (iii) whether it has processes to oversee and identify cyber risks associated with its use of any third-party service provider.

Paragraph (b)(2) asks whether any cyber risks, including from previous incidents, have materially affected or are reasonably likely to materially affect the business, and if so how.

Item 106(c), governance. Paragraph (c)(1) covers the board's oversight, including any committee responsible and how it is informed. Paragraph (c)(2) covers management's role: which positions or committees are responsible and their relevant expertise, how they are informed about and monitor the prevention, detection, mitigation and remediation of incidents, and whether they report to the board or a board committee.

Form 8-K Item 1.05, incidents. A company that determines a cybersecurity incident is material files an Item 1.05 Form 8-K within four business days of that determination, describing the material aspects of its nature, scope and timing, and its material or reasonably likely impact. Instruction 1 says the materiality determination must be made without unreasonable delay after discovery. Instruction 4 says the company need not disclose technical detail about its response or systems that would impede the response or remediation. There is a narrow delay route where the US Attorney General finds immediate disclosure would pose a substantial risk to national security or public safety.

Dates. Item 106 applied from annual reports for fiscal years ending on or after 15 December 2023. Item 1.05 applied from 18 December 2023 for most registrants and from 15 June 2024 for smaller reporting companies.

Registration statements. During the rulemaking, the SEC's Investor Advisory Committee recommended extending Items 106(b) and 106(c) to registration statements, noting that "pre-IPO companies may face heightened" cyber risks. The adopted text calls for the Item 106 information in the annual report, through new Form 10-K Item 1C; foreign private issuers use the parallel Form 20-F Item 16K. What your registration statement says about cybersecurity, in risk factors or elsewhere, is a question for your securities counsel.

What this means for a pre-IPO engineering leader:

• You will describe your processes in your first Form 10-K after listing. Whatever goes there should describe a process that already runs, not one you plan to build.
• Item 106(b)(1)(iii) asks about third-party service providers. Your build services, package registries and hosted dependencies sit squarely in that conversation, and your open source components are the third-party code you ship.
• Item 106(c)(2)(ii) asks how management is informed about prevention, detection, mitigation and remediation. A monthly metrics page and a risk register entry are the simplest honest answer.
• The four business day clock starts at the materiality determination, and that determination cannot be delayed unreasonably. Engineering's job is to make sure the facts that feed it (what is affected, since when, what data, what fix) can be assembled in hours, not weeks.

This is not legal advice. Do not draft disclosure language from an engineering wiki; give counsel accurate facts and let them draft.

SOC 2 Type II: controls that operated, not controls that exist

A SOC 2 examination is performed by a CPA firm against the AICPA's Trust Services Criteria (the current set is the 2017 criteria with points of focus revised in 2022). A Type II report covers a period of time, and the auditor tests whether the controls in your system description actually operated through that period. The security common criteria include system operations, which is where vulnerability detection and monitoring sit, and change management, which is where authorising, testing and approving changes before they reach production sit. Your auditor will tell you exactly which criteria and points of focus they test against; ask early.

For an AppSec program with no dedicated team, the risk is not a missing policy. It is a gap between the policy and the pipeline. If your policy says "critical vulnerabilities are fixed within 15 days" and the auditor samples ten that took 60, that is an exception in the report. Write the timeline you can hit, then hit it. Our guide to SOC 2 Type II for SaaS startups covers the audit itself in more depth.

NIST SSDF: a shared vocabulary for "secure development"

NIST SP 800-218, the Secure Software Development Framework (version 1.1, published February 2022), groups practices into four families: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). It is not a pre-IPO requirement. It is useful because underwriters, enterprise customers and auditors increasingly recognise its practice IDs, so mapping your 90 day plan to them gives everyone a common reference.

The practices most relevant to the first 90 days:

• PO.1 and PO.2: define security requirements for software development and assign roles and responsibilities.
• PS.1 and PS.3: protect code from unauthorised access and tampering, and archive and protect each software release.
• PW.4: reuse existing, well-secured software where feasible, which includes checking third party components.
• RV.1 and RV.2: identify and confirm vulnerabilities on an ongoing basis, then assess, prioritise and remediate them.

NIST CSF 2.0: governance gets its own function

NIST's Cybersecurity Framework 2.0 (CSWP 29, 26 February 2024) organises outcomes under six functions: Govern, Identify, Protect, Detect, Respond and Recover. Govern is the new one. NIST describes it as the function under which the organisation's cyber risk management strategy, expectations and policy are established, communicated and monitored, and it includes a cybersecurity supply chain risk management category, GV.SC. If your board or audit committee wants a single frame for cyber oversight, CSF 2.0 is a reasonable choice, and its Govern categories line up well with what Item 106(c) asks about.

KEV and EPSS: two free signals for ranking what to fix

CISA describes its Known Exploited Vulnerabilities catalog as the authoritative source of vulnerabilities that have been exploited in the wild, and says organisations should use it as an input to their vulnerability management prioritisation. FIRST's Exploit Prediction Scoring System estimates the probability that a published CVE will be exploited in the wild in the next 30 days. Neither replaces your judgment, but together they turn "we have 4,000 open findings" into "we have a few dozen that are known exploited or likely to be, and these are the ones to fix first."

For federal agencies, CISA's BOD 26-04, "Prioritizing Security Updates Based on Risk" (10 June 2026), now sets how remediation is prioritised; it supersedes and revokes BOD 22-01, and KEV status is one of the factors it asks agencies to weigh. A private company is not bound by it, but using KEV as a fix priority signal is a defensible, explainable choice that an auditor or investor will recognise.

OWASP SAMM: a maturity yardstick that fits a small team

The OWASP Software Assurance Maturity Model defines five business functions (Governance, Design, Implementation, Verification and Operations) and fifteen security practices under them. SAMM does not expect every organisation to reach the top maturity level everywhere; you pick a target level per practice. It is free and vendor neutral, and it gives you a way to say "this is where we are, and this is where we will be by the first annual report" without inventing a scale.

Step by step: the first 90 days, with or without Safeguard

The plan below assumes a SaaS scale-up with a few hundred engineers or fewer, one main cloud provider, a single source control platform, and a CI system the platform team owns. Adjust the timings, but keep the order. Owner first, inventory second, rules third, gates fourth, evidence throughout.

Days 1 to 10: name the owner and write the charter

1. Name one accountable owner. Until you hire, that is probably you or a staff engineer you trust. Write it down. Item 106(c) will eventually ask which management positions are responsible, and SOC 2 auditors look for assigned responsibility.
2. Write a one page AppSec charter. Scope (which products, repositories and environments), the owner, who they report to, how often they report to the board or audit committee, and the decision rights: who can approve an exception, and for how long.
3. Pick the frameworks you will map to. For most pre-IPO SaaS companies that is SOC 2 for the audit, NIST SSDF for development practices and NIST CSF 2.0 for governance. Do not add more until these work.
4. Agree the severity scale and fix timelines. Use a table like the one below, and get sign off from engineering leadership and whoever owns the SOC 2 program. Start with timelines you can hit; tighten them in the next cycle.

These numbers are illustrative. Write your own, and only write what your teams can meet across the whole observation window.

Days 5 to 30: inventory everything you build and ship

5. List every repository in your source control platform, then mark each as production, internal tool, experiment or archived. Archive what nobody owns.
6. Map repositories to services and services to environments. A spreadsheet is fine. The question you are answering is "if this library is vulnerable, which customer facing services are affected?"
7. Generate an SBOM for every production service. Use SPDX or CycloneDX. Store them per release, not just "latest," because diligence and incident response both ask "what was running on this date?"
8. Inventory container base images and where they come from.
9. List your build and deploy dependencies: CI runners, package registries, artifact stores, third party actions and plugins. These are part of your third party surface.
10. Record licenses for every third party component. Copyleft and network copyleft licenses in distributed code are a classic diligence question. If you ship an on-prem or desktop product, this matters more than for pure SaaS.

Days 20 to 45: write the rules down before you enforce them

11. Write the release policy in plain language first. For example: "No release ships with a known exploited vulnerability that is reachable in production code. No release ships with a component under a license on the denied list. No release ships without an SBOM."
12. Decide the action for each rule. Most gate systems support three outcomes: block the build, warn and let it through, or notify an owner. Start new rules in warn or notify, measure the noise for two weeks, then switch the important ones to block.
13. Define the exception path. Every block needs a way through for the rare legitimate case. An exception should have an owner, a reason, an expiry date and a record. The exception register is evidence in itself; an auditor wants to see that exceptions are rare, approved by the right person and closed on time.

Days 30 to 60: gate new risk, rank old risk

14. Put the gate in CI for every production repository, on every pull request and every release build. A gate that only runs nightly does not stop anything from shipping.
15. Stop the bleeding before you drain the pool. New pull requests should not add new critical, reachable findings. That is the first metric to get to zero.
16. Rank the existing backlog. Sort by known exploitation (KEV), exploit likelihood (EPSS), reachability and the business criticality of the service. Most teams find that a small fraction of findings deserve this quarter's attention.
17. Fix with pull requests, not tickets. A ticket that says "upgrade library X" waits in a backlog. A pull request that upgrades library X, runs the tests and shows the diff gets reviewed. Whatever tooling you use, aim for fix proposals that land in the developer's normal review flow.
18. Add first party code testing. Static analysis on pull requests for the main languages, and dynamic testing against a staging environment you own and have verified. Start narrow; a few high signal rules beat a thousand noisy ones.

Days 45 to 75: make the work leave evidence

19. Keep every gate decision. Pass, warn, block, the policy that fired and the commit. This is the change management evidence your SOC 2 auditor will sample.
20. Keep every exception with its approver and expiry.
21. Keep SBOMs per release and a record of which vulnerabilities were open on each release date.
22. Track fix times from detection to merged fix, by severity, against the timelines you set on day 10.

Days 60 to 90: report, register and hire

23. Build a one page board metric set. Keep it to five or six numbers that move. See the metrics table below.
24. Add application security to the enterprise risk register, with an owner, the controls that treat it, and a residual rating. Item 106(b) asks whether cyber risk processes are integrated into overall risk management; a register entry is the simplest proof.
25. Run a tabletop for a dependency compromise. Walk through "a library we use is backdoored" or "a known exploited vulnerability in our main framework." Time how long it takes to answer: which services, which versions, since when, what data, what fix. That number is what feeds the 8-K materiality conversation later.
26. Write the first AppSec hire's job description around what you built. They inherit a working process and a ranked backlog, not a blank page.

The metrics that belong in a board pack

Avoid raw finding counts. They go up when you add a scanner and down when you remove one, and they tell the board nothing about risk. There is more on choosing program metrics in measuring AppSec program effectiveness.

A day 90 readiness checklist

• One named owner with written decision rights.
• A charter and a release policy, both approved and dated.
• An inventory of repositories, services, images and build dependencies.
• SBOMs per production release, stored and retrievable.
• License review recorded for third party components.
• CI gates on every production repository, with block, warn and notify set deliberately.
• An exception register with owners and expiry dates.
• A ranked backlog with known exploited and reachable items tracked to the timelines.
• Board metrics for one quarter.
• An application security entry on the risk register.
• One completed tabletop with a timed "are we affected?" answer.
• A job description for the first AppSec hire.

Who owns AppSec before the first security hire?

Somebody with authority over the code, the pipelines and the release decision. In most scale-ups that is the VP of Engineering or the CTO. It should not be a committee, and it should not be the cloud security engineer who already owns identity and infrastructure, unless you give them real authority and take something else off their plate.

The owner does not have to do the work. They decide the rules, approve exceptions above a threshold, report to the board and are accountable when the process slips. Engineering managers own the fixes in their services. The platform team owns the gates. Write those three roles into the charter.

What do underwriters and their counsel usually ask about application security?

Diligence lists vary by bank and counsel, and nobody can tell you what yours will say. In general, the cyber section asks for policies, a description of how you manage vulnerabilities, your history of material incidents, how you manage third party and open source risk, penetration test summaries, and how the board is informed. They are testing whether what you will eventually disclose is true.

If you want the open source part of diligence in detail (licenses, fix history, what goes in the data room and what stays out), our companion post on getting open source risk ready for pre-IPO diligence covers it. This post is about standing up the function that produces those answers.

Should you hire first or put tooling in first?

Both, in parallel, but do not wait for the hire. Senior AppSec hires often take months to land. If the first one arrives to find a working inventory, gates in CI and a ranked backlog, they spend their first quarter on design reviews, threat modelling and the hard problems. If they arrive to a blank page, they spend it building what you could have built.

A useful test: if your first AppSec lead resigned on day one, would the process keep running? If yes, you built a function. If no, you hired a person. For the wider hiring sequence beyond AppSec, see building a security team from scratch.

What does "reachable" mean, and why does it matter here?

A vulnerability in a library is only exploitable through your application if your code actually reaches the vulnerable function, directly or through the dependency chain, with input an attacker can influence. Reachability analysis tries to answer that question from your code and configuration.

For a team with no AppSec function, it matters because it is the difference between "fix 4,000 things" and "fix the few dozen that are actually exposed." It also gives you a defensible reason, written down per finding, for why something sits at a lower priority. Treat reachability as evidence for prioritisation, not proof of safety. Code paths change with every release, and dynamic behaviour (reflection, plugins, configuration driven routing) can hide a path a static analysis misses.

How do you keep SOC 2 and the IPO workstream from becoming two programs?

Use one set of controls and one evidence store. The release policy you write for engineering is the change management control in your SOC 2 system description. The exception register is your evidence that exceptions are approved. The fix time metric is your vulnerability management control. The board pack is your governance evidence, and later the raw material for the Item 106 description.

If your compliance consultant and your engineering team are keeping separate spreadsheets for the same control, merge them now. The auditor will sample one, the underwriters will read the other, and they must agree.

What about open source licenses?

For a pure SaaS business, most copyleft licenses only create obligations when you distribute the software. Network copyleft licenses can create obligations when users interact with the software over a network. If you ship anything customers install (an agent, a desktop app, an on-prem edition, an SDK), the full range of license obligations applies to what you ship.

In the first 90 days, the goal is a recorded license for every third party component in every production service, a denied list agreed with counsel, and a gate that warns on anything new from that list. The deeper legal analysis belongs to counsel.

How Safeguard does this

Everything above works with spreadsheets and a handful of open source tools. Safeguard puts the inventory, the rules, the gates, the ranking, the fixes and the evidence in one place, so the process keeps running while you hire. Every capability below is generally available (GA). Screens and commands are described as Safeguard's docs show them; the commands were not run for this post.

1. Connect source control and registries. In Settings → Integrations, connect your source control provider (the onboarding docs list GitHub, GitLab, Bitbucket, Azure Repos and AWS CodeCommit), authorise access and select the repositories to monitor. Container registries connect from the same screen. Start with the repositories you marked production on day 5.
2. Add projects and generate SBOMs (GA). In Projects, click + Add Project, choose the integration source and the repository or image, and set the branch or version. SBOM generation and analysis (GA) produces SPDX and CycloneDX documents, and SCA with deep transitive dependency scanning (GA) builds the full component tree. Each project then has tabs for Dependencies, Vulnerabilities, Mitigations, Security Posture, Suppliers & Licenses and Findings, which together are most of your day 30 inventory.
3. Rank the backlog (GA). Vulnerability management (GA) enriches findings with EPSS and CISA KEV. Reachability analysis and prioritisation (GA) classifies each finding as reachable, conditionally reachable, unreachable or unknown, and treats unknown conservatively as potentially reachable. Priority combines reachability, exploitability, runtime context and the business context you declare by policy, and the weights are configurable per tenant under Settings → Prioritization. The vulnerabilities table sorts by priority by default, which is the ranking you wrote on day 10.
4. Write the release policy (GA). In Settings → Policies, click Create Policy and define conditions in the visual builder or in YAML. The documented conditions include vulnerability severity, CVSS score, EPSS score, license, component age and maintenance status, and there are templates such as "No Critical Vulnerabilities" and "License Compliance." Policies can also be created from plain English prompts.
5. Choose the action for each policy. Each policy has one Action that decides what a failed policy does to its gate: Block (the gate fails), Warn (the gate passes with a warning naming the policy) or Notify (the gate passes and a notification is sent). Start new rules on Warn, and move the ones you agreed to enforce to Block after two weeks of data.
6. Route the rare legitimate case through an exception. A developer clicks Request Exception, selects the policy and finding, gives a business justification and sets an expiration date. Approvers are notified, decide, and an audit trail is recorded. That trail is your exception register.
7. Run it in CI. The GitHub Actions page shows the workflow below, using a secret key created under Settings → Developer with the scans:trigger and scans:read scopes and stored as the repository secret SAFEGUARD_API_KEY:

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

To fail the job on your policy gates rather than on a severity threshold, the docs say to add --fail-on-gate all. Gate failures in CI depend on policy outcomes, which Safeguard turns on per workspace; if your workspace does not show an Outcome column on the Gates and Policies tables, ask Safeguard to enable it. The docs show equivalent pages for GitLab CI/CD, Bitbucket Pipelines, Jenkins and Azure Pipelines. 8. Keep source code on your machines if you need to (GA). The CLI and local runner (GA) install with curl -fsSL https://cli.safeguard.sh/install | bash. Run safeguard, type /login, approve in the browser, and the machine starts polling for scan jobs. It runs them locally and uploads only the resulting SBOM and findings, never the source code. All traffic is outbound HTTPS that the runner opens. 9. Apply the license denied list (GA). License compliance (GA) recognises SPDX identifiers and full SPDX expressions, and classifies licenses as permissive, weak copyleft, strong copyleft or network copyleft. The docs rate network copyleft high risk for SaaS. You declare allow and deny lists as a policy, scoped by asset label if your on-prem edition needs a stricter list than your SaaS backend, and a new direct dependency with a denied license gets a blocking check at pull request time. The docs note there is no CLI command for license reports yet. 10. Test your own code (GA). SAST (GA) analyses first party code with dataflow traces mapped to CWE and OWASP categories. DAST (GA) runs safe, scoped dynamic testing against targets you have verified you own. 11. Fix with pull requests (GA, ships off). On a project's Vulnerabilities tab, click AI Remediate, review the proposed fix and click Create Pull Request. Autonomous remediation (GA) can also open fix pull requests on its own, in bulk across repositories, once you enable Automatic PR Creation under Settings → AI Remediate. It ships switched off, with every category set to Manual, so nothing runs on its own until you decide it should. 12. Answer "are we affected?" in one query (GA). The Search page runs natural language queries across all your SBOMs, components and vulnerabilities, powered by Safeguard's Griffin models. This is the question your tabletop timed. 13. Map the work to frameworks (GA). The compliance and GRC suite (GA) includes SOC 2, NIST SSDF and NIST CSF 2.0 framework pages, each on in your workspace unless you switch it off in Compliance › Manage. The SBOMs, gate outcomes and exceptions above become evidence against the controls; requirements a scan cannot see are passed by a person attesting with evidence. 14. Answer customers and diligence from one page (GA). Trust Center (GA) publishes a page showing the frameworks you choose, each with a status, plus live control areas, policies, subprocessors and documents. Publishing is always an explicit action, and restricted documents go out through access requests under NDA with an audit trail.

What Safeguard does not do

• It does not decide materiality or draft disclosure. Whether an incident is material, and what goes in a registration statement or a Form 8-K, is a decision for management, the board and securities counsel.
• It does not issue your SOC 2 report. Safeguard collects and maps evidence. A licensed CPA firm performs the examination and issues the report. Safeguard's own SOC 2 Type II audit is in progress.
• It does not replace your first AppSec hire. It runs the repeatable parts (inventory, gates, ranking, fix proposals, evidence) so the person you hire spends time on design review, threat modelling and judgment calls that tooling cannot make.
• It does not set your risk appetite. Severity thresholds, fix timelines and who can approve an exception are your decisions. Safeguard enforces what you write.
• It does not fix vendor or hosted services you do not build. When the vulnerable code sits in a SaaS provider, an appliance or a managed runtime, the fix still has to come from that vendor.
• It does not turn on automatic fixes by itself. Autonomous remediation ships off, every category set to Manual. Pull requests still need your review and your tests.
• Reachability is evidence, not proof. A finding ranked lower because it is not reachable today can become reachable after a refactor. Keep re-scanning, and keep known exploited items on a short clock regardless.

Common mistakes

• Buying four tools before naming one owner. Tools without a decision maker produce dashboards nobody acts on.
• Turning every rule to block on day one. Engineering will route around a gate that fires on everything. Start in warn, measure, then block the few rules that matter.
• Writing fix timelines you cannot meet. A SOC 2 Type II report tests whether you met the timeline you wrote. Aspirational numbers become exceptions in the report.
• Reporting raw finding counts to the board. They measure scanner coverage, not risk. Report known exploited and reachable items, fix times and exceptions.
• Keeping SOC 2 evidence and engineering reality in different places. When the auditor and the underwriters see different numbers, both conversations get harder.
• Treating the IPO as the deadline. The first annual report after listing is when you describe your processes. The work has to have been running long enough to describe honestly.
• Ignoring the build system. CI runners, third party actions and package registries are part of your supply chain. Inventory them with the same care as runtime dependencies.
• Letting exceptions live forever. Every exception needs an expiry date. An exception register with no closed entries is a finding waiting to happen.

FAQ

Do we need an AppSec team before we file an S-1?

There is no rule that says you need a team of a particular size. What you need is a process you can describe accurately, an owner with authority, and evidence that the process runs. Many companies go public with one or two dedicated application security people supported by engineering and good tooling.

When does Regulation S-K Item 106 apply to us?

Item 106 disclosure goes in the annual report on Form 10-K. Your counsel will tell you exactly when your first one is due and what, if anything, a registration statement should say about cybersecurity. Plan on your processes having run for at least a year by the time you describe them.

What is the four business day rule?

Form 8-K Item 1.05 requires disclosure of a material cybersecurity incident, generally within four business days after the company determines the incident is material. The determination itself has to be made without unreasonable delay after discovery. Engineering's role is to get the facts fast.

Is SOC 2 Type II enough for IPO diligence?

It helps, because it shows controls operated over a period, and diligence teams often ask for it. It is not a substitute for a description of your vulnerability management, third party risk and governance processes, which is what Item 106 asks about.

Which framework should a pre-IPO company use for AppSec?

Use SOC 2 for the audit, NIST SSDF for secure development practices and NIST CSF 2.0 for governance and board reporting. OWASP SAMM is a good internal maturity yardstick. Do not add more until these run.

How many vulnerabilities is "too many" to go public with?

There is no number. Investors and auditors care whether you know what you have, whether you fix what matters in the time you said you would, and whether exceptions are controlled. A small backlog of known exploited, reachable issues is a bigger problem than a large backlog of unreachable low severity ones.

What should the first AppSec hire own?

Threat modelling and design review for new systems, the security requirements in the charter, triage of the hard findings, the exception decisions above the owner's threshold, and the relationship with the SOC 2 auditor on application controls. The repeatable work should already run.

How do we report application security to the board?

Five or six metrics that move: production services with a current SBOM, open known exploited and reachable vulnerabilities, median days to fix by severity, releases blocked, exceptions granted and past expiry, and the time to answer "are we affected?" in the last tabletop.

Can we keep source code out of a SaaS security tool?

Yes, with the right setup. Some tools, Safeguard included, offer a local runner that scans on your own machines and sends only results. Ask any vendor exactly what leaves your network.

The 90 day plan works only if the ranked backlog actually shrinks, and most of that backlog is open source code your teams did not write. Here is how Safeguard closes that gap, both when a fixed version exists and when it does not 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 CLI demo is a real terminal session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix a lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to the fixed version, runs the install and the tests with your approval, prints a summary and pushes nothing. For an engineering team with no AppSec function, that is what "fix with pull requests, not tickets" looks like on one developer's machine.

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

The local runner demo shows the runner being set up on your own machine, approved with its device code, and a scan started from the terminal. If counsel or your largest customers are uneasy about granting a hosted service access to source code during the IPO process, this is the route from step 8 above.

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

The Claude demo shows Claude connected to the Safeguard MCP server with OAuth, and you choosing which Safeguard tools Claude may use. For a VP of Engineering who already works in an assistant, it is a way to pull the board metrics or check exposure without opening another console, with the tool permissions set by you.

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

Quick check

Sources

• SEC final rule: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure, 88 FR 51896, 4 August 2023 (govinfo)
• AICPA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• NIST SP 800-218, Secure Software Development Framework version 1.1 (CSRC)
• NIST SP 800-218 full text (PDF)
• NIST Cybersecurity Framework 2.0, CSWP 29 (PDF)
• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• FIRST: Exploit Prediction Scoring System
• OWASP SAMM: The Model
• OWASP SAMM: About
• Safeguard docs: Onboarding Workflow
• Safeguard docs: Policies & Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: GitHub Actions
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Local Runner
• Safeguard docs: License Compliance
• Safeguard docs: Search
• Safeguard docs: SOC 2 framework
• Safeguard docs: NIST SSDF framework
• Safeguard docs: NIST CSF 2.0 framework
• Safeguard docs: Trust Center

Start with a free scan from safeguard.sh/download, and read the setup guides at docs.safeguard.sh.

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