Keep AppSec coverage through a security hiring freeze

When the AppSec requisition freezes and an engineer walks out the same month, you keep coverage by planning for two quarters, not by asking the remaining team to absorb everything. Decide in writing what stops, what gets automated, what moves to engineering owners with clear rules, and what risk you accept with a named owner and an expiry date. Then show the executive team the exposure the freeze creates in risk terms, and agree the restart order before the freeze lifts.

This plan is written for a CISO at a B2B SaaS company. Most of it works with whatever tools you run; the Safeguard part is marked.

Key takeaways

• A freeze is temporary, so treat it as a two quarter operating plan with a start date, an end date and a restart order. Open ended "do more with less" is how coverage quietly erodes.
• Some work cannot pause: known exploited vulnerabilities in internet facing products, the release gates on your highest risk products, and anything you have promised customers in contracts or security reviews.
• Tier products and repositories by exposure and data before you reassign a single hour. The people you still have cover tier 1 first.
• Engineering owners can carry more of the routine load if the rules are written as policies with clear actions, an exception path and a named approver.
• NIST SP 800-40 Rev. 4 names four risk responses: accept, mitigate, transfer and avoid. During a freeze you will accept more risk than usual, so every acceptance needs an owner, a reason and an expiry.
• Report the freeze to executives as exposure (what is unreviewed, what is open past target, what is accepted and until when), not as hours.
• In Safeguard, the matching flow uses policies, gates and guardrails with plain English policy creation (GA), reachability analysis and prioritisation (GA), Griffin fix pull requests through autonomous remediation (GA, ships switched off with every category set to Manual), Jira and Slack routing through notifications and ticketing (GA), dashboards with scheduled reports (GA), plus SCA and vulnerability management (GA), the CLI in CI (GA) and the MCP server (GA). None of it replaces the engineer you lost.

The situation

You run security for a SaaS company that sells to other businesses. Your AppSec function was small to begin with: a handful of engineers covering dozens of services, several product lines, a release train that ships every week, and a steady stream of customer security questionnaires. Then two things happen in the same month. A security engineer resigns, and finance freezes the open requisition you were about to fill, plus the backfill.

Sales still expects security review answers within the week, the board still expects the quarterly risk slide, and the person who left owned the dependency backlog and two product lines' design reviews.

A bad week during a freeze looks like this. A vulnerability lands on the CISA Known Exploited Vulnerabilities catalog on a Tuesday, in a library used by one of your internet facing APIs. The person who would have triaged it is gone. The ticket sits in a queue that nobody watches closely anymore. Meanwhile a large prospect sends a 300 question security review with a two week deadline, and your remaining engineers spend that week on the questionnaire instead of the exploited vulnerability. Nothing is decided; things just slip.

The fix is a written plan that makes the trade offs visible and puts names on them.

The rules and standards behind it

None of the documents below say "here is what to do in a hiring freeze". They do define what a defensible vulnerability and secure development program looks like, and they give you vocabulary your auditors, customers and board already recognise. This is not legal, regulatory or audit advice; read the primary texts and decide with your own counsel and auditors how they apply to you.

NIST SP 800-40 Rev. 4: four risk responses and maintenance groups

NIST's patch management guide, SP 800-40 Rev. 4, is the clearest source for how to talk about vulnerabilities you cannot fix right away. Section 2.1 lists four risk responses:

• Accept the risk as is, for example by relying on existing controls or deciding the impact is low enough.
• Mitigate it, by patching, upgrading, disabling a feature or adding controls such as segmentation.
• Transfer it, by sharing consequences with another party, for example insurance or a provider that handles patching.
• Avoid it, by removing the attack surface: uninstall, decommission or disable.

The same section notes that by default an organisation already accepts the risk of the software it runs. A freeze makes that acceptance larger and, unless written down, invisible.

Section 2.2 describes the life cycle as know, plan, execute and continuously monitor the risk response; an acceptance has to be checked, not just recorded once.

Section 3.3 asks organisations to define risk response scenarios, and names routine patching, emergency patching, emergency mitigation and unpatchable assets. Section 3.4 asks you to put each asset into a maintenance group with similar needs. That is the tiering exercise below, in NIST's words. Section 3.6 warns that overly simple metrics, such as a raw count of vulnerabilities and the percentage patched, are not actionable, and shows a notional matrix of mitigation time by asset importance and vulnerability importance. That matrix is the right shape for your freeze report.

NIST SP 800-218 (SSDF): roles, management commitment and risk responses

The Secure Software Development Framework, SP 800-218, is what many customers and federal buyers point to when they ask how you build software. Three tasks map directly onto a freeze:

• PO.2.1 asks you to create new roles and alter responsibilities for existing roles as needed to cover all parts of the SDLC, and to review them periodically. Moving routine AppSec work to engineering owners is exactly this, and it should be written down as a role change, not an informal favour.
• PO.2.3 asks for upper management or authorising official commitment to secure development, conveyed to everyone with development related roles. A freeze is a management decision; the acceptance of its consequences should be one too.
• RV.2.2 asks you to plan and implement risk responses for vulnerabilities, including a risk based decision on whether each vulnerability will be remediated or addressed through other means such as risk acceptance or transference.

NIST CSF 2.0: roles, resources and recorded exceptions

The Cybersecurity Framework 2.0 Govern function gives you board language. GV.RR-01 says organisational leadership is responsible and accountable for cybersecurity risk. GV.RR-02 asks that roles, responsibilities and authorities are established, communicated, understood and enforced. GV.RR-03 asks that adequate resources are allocated commensurate with the cybersecurity risk strategy. A freeze is, plainly, a GV.RR-03 decision, and the honest response is to say what the strategy can and cannot cover with the resources left.

Two more outcomes help. GV.RM-02 asks for risk appetite and risk tolerance statements that are established, communicated and maintained. ID.RA-07 asks that changes and exceptions are managed, assessed for risk impact, recorded and tracked. Your freeze plan is a temporary change to your risk tolerance, and your accepted risks are exceptions. Both belong on record.

CISA KEV, BOD 26-04 and EPSS: what cannot wait

CISA maintains the Known Exploited Vulnerabilities catalog and says organisations should use it as an input to their vulnerability management prioritisation. For a freeze, KEV is your floor: a KEV listed vulnerability in an exposed product does not go on the "pause" list.

Binding Operational Directive 26-04, issued 10 June 2026, applies to US federal civilian agencies, not to a private SaaS company. It is still a useful model. It revoked BOD 22-01 and BOD 19-02, and it sets remediation urgency from four factors: whether the asset is publicly exposed, whether the vulnerability is on KEV, whether exploitation can be automated, and whether exploitation gives partial or total control. Its tightest timelines pair a three day remediation window with a forensic triage of the asset. If your federal customers ask how you prioritise, showing that your freeze plan uses the same four questions is a strong answer.

FIRST's Exploit Prediction Scoring System (EPSS) estimates the probability that a published CVE will be exploited in the wild in the next 30 days, and publishes a fresh score for every CVE daily. It is the second filter after KEV when you have fewer people than findings.

OWASP SAMM and CISA Secure by Design: what a program should still look like

OWASP SAMM organises software security into five business functions (Governance, Design, Implementation, Verification and Operations) and fifteen practices. Naming the practices you pause in SAMM terms, usually Design ones such as threat assessment, makes the restart plan concrete.

CISA's Secure by Design guidance says technology providers must take ownership of product security at the executive level. The freeze is the executive team's decision to own with you, not a gap for security to absorb quietly.

Step by step: a two quarter freeze plan, with or without new tools

The plan below assumes two quarters, roughly 26 weeks. If your freeze is shorter, compress it; if it is longer, run it again at the half year with fresh numbers.

Step 1. Write down what the person who left actually did

Pull the departed engineer's tickets, calendar and on call history for the last two quarters, and group the work:

1. Recurring work with a schedule (weekly dependency triage, monthly access reviews, quarterly pen test coordination).
2. Work triggered by events (new KEV entries, incident support, release sign offs).
3. Work owned by product line (design reviews, threat models, security champion support for two product teams).
4. Customer facing work (security questionnaires, customer calls, contract security schedules).

Do the same, briefly, for each engineer who remains.

Step 2. Sort every activity into stop, automate, delegate, accept or keep

Use one table. It becomes the core of your freeze plan and the record your auditors will ask for later.

Keep the decisions distinct. Stop means nobody does it and you say so. Automate means a tool does it and a named person reviews the output. Delegate means another team owns it under written rules. Accept means the risk stays, with an owner and an expiry. Keep comes first.

Step 3. Tier products and repositories by risk

NIST SP 800-40 Rev. 4 calls these maintenance groups. Call them tiers if that is the house word. Score each product, then roll repositories up to the product they ship in.

A product that scores tier 1 on exposure or data is tier 1, whatever the other columns say. Write the list down, get engineering leaders to agree it, and publish it. Disputes over tiers are cheaper now than during an incident.

Step 4. Set freeze service levels per tier

Your normal remediation targets were sized for a full team. Set temporary ones that the remaining team can actually meet, and say so in writing. A worked example, with round invented numbers you should replace with your own:

The first row does not move. Everything else is a deliberate, temporary loosening that you report as such. If BOD 26-04's four factors are useful to your customers, map them in: public exposure and KEV status decide the row, and automation and technical impact can move a finding up a band.

Step 5. Turn the delegated work into written rules

For each delegated activity write:

1. The rule, in one sentence ("No new critical vulnerabilities in dependencies on tier 2 repositories").
2. What happens when it is broken: the build fails, the build passes with a warning, or a notification goes to the owning team.
3. The exception path: who can approve an exception, what justification they need, and the longest expiry they can grant.
4. Where help comes from: office hours, a Slack channel, a short runbook.

Keep the rules few; five that engineering accepts beat thirty that teams route around.

Step 6. Build the risk acceptance record

Every acceptance during the freeze uses the same record. Here is a template you can paste into a ticket or a risk register entry:

Risk acceptance record
ID:                    RA-2026-Q4-017
Product and tier:      Internal reporting tool, tier 3
Finding or activity:   High severity vulnerability in a transitive dependency,
                       or "no threat model for feature X"
Risk response chosen:  Accept (NIST SP 800-40 Rev. 4, section 2.1)
Why:                   Internal only, no customer data, upgrade blocked by
                       framework major version
Existing controls:     SSO required, network restricted to corporate VPN
Owner:                 Engineering director, reporting tools
Approver:              CISO
Created:               2026-10-25
Expires:               2027-03-31 (freeze end plus one month)
Review trigger:        Finding added to CISA KEV, EPSS rises sharply,
                       exposure changes, or the tool starts handling customer data
Restart action:        Upgrade in first sprint after freeze ends

Three fields do most of the work: an owner who is not you, an expiry date, and review triggers that reopen the decision early. NIST SP 800-40 Rev. 4 section 2.2 asks you to continuously monitor the risk response; the review triggers are how you do that without a person reading the register every day.

Step 7. Agree what you tell customers and sales

Refresh a library of approved answers to common security review questions, route questionnaires through one intake with a realistic turnaround, and never change a contractual commitment silently.

Step 8. Brief the executive team on exposure, not hours

The executive conversation goes better when it is about risk the company is choosing to carry. Use one page, refreshed monthly:

The numbers are an illustrative worked example. Show what has not moved, what is worsening within limits and what has crossed a limit.

Step 9. Agree the restart order now, and review monthly

Write the restart order before anyone forgets what was paused (a default is below). Check the plan monthly against new products, commitments and KEV entries, and at the half way point decide with executives whether it holds or needs an exception for one hire.

Which AppSec activities can pause for two quarters, and which cannot?

The test is simple: can a delay cause a known exploitation, a broken promise or an unreviewed change to your most exposed product? If yes, it cannot pause.

Cannot pause:

• Triage and response for KEV listed vulnerabilities in anything exposed or tier 1. CISA says exploitation is not hypothetical for these.
• Release gates on tier 1 products. If the gate needs a human sign off and you no longer have the human, convert as much of it as possible to automated checks with a narrow manual review, rather than skipping it.
• Commitments in customer contracts, data processing agreements and completed security reviews: notification windows, test cadence, specific controls.
• Incident response support, unless formally moved to another rota.
• Anything a regulator or auditor has already been told is in place.

Can usually pause, with a written decision:

• New threat models for small or internal features. Keep them for tier 1 changes that alter authentication, authorisation, data flows or external exposure.
• Champion training sessions and security awareness content for engineers. Keep office hours.
• Remediation of medium and low findings on tier 3 systems, through recorded acceptance.
• Program improvement projects and manual review of routine tier 2 and 3 changes that automated checks cover.

Pause with care: design reviews for tier 1 features. A middle path is a 30 minute checklist review instead of a full one.

How do you tier products and repositories so the remaining people cover the riskiest first?

Start from the product, not the repository. Repositories are how engineers see the world; products are how customers and attackers see it. Map every repository to the product or shared service it ships in, then tier the product with the table in Step 3.

Three practical points:

1. Shared libraries inherit the highest tier of anything that uses them.
2. Abandoned repositories count if they build something that runs.
3. Write down who owns each repository. CSF 2.0 GV.RR-02 asks that roles are understood and enforced; an unowned repository is one nobody will fix.

Then assign your remaining people by tier, not by product line. If you had one engineer per product line before, during the freeze one person might hold all tier 1 dependency triage across products while another holds tier 1 design reviews and customer reviews. Tier 2 and 3 work moves to engineering owners under the rules in Step 5.

What can move to engineering owners with clear policies, and what support do they need?

SSDF PO.2.1 is explicit that roles can change to cover the SDLC; the freeze is a reason to do that deliberately.

Good candidates to move:

• Merging dependency upgrade pull requests on tier 2 and 3 repositories, including ones a tool opens automatically.
• Fixing findings that fail an automated policy in their own pipeline, within the freeze service levels.
• Requesting an exception when they cannot fix in time, with a written justification and an expiry.
• Keeping their repository's ownership and tier metadata current.

Poor candidates to move:

• Approving exceptions for their own team. The approver should be outside the team that benefits.
• Threat modelling for tier 1 changes. Engineering can draft; security should review.
• Answering customer security questions about architecture without review.
• Deciding whether a KEV listed vulnerability is exploitable in context.

What they need from you:

1. A short list of policies, each with a clear action when it fails.
2. Fix guidance where they work, ideally a ready made pull request rather than a ticket.
3. One channel for questions, and office hours with a named person.
4. A scoreboard per team against the freeze targets.
5. Their director's agreement that this work is part of the job during the freeze.

The longer version of this split, for steady state rather than a freeze, is in security champions vs the security team: who owns what.

How do you document accepted risk with an owner and an expiry?

Use the record in Step 6 and keep three rules.

Rule 1: use NIST's vocabulary. Write accept, mitigate, transfer or avoid from SP 800-40 Rev. 4 section 2.1, and when you accept, name the existing controls you rely on. Auditors and customers read standard words quickly.

Rule 2: every acceptance expires. During a freeze, the default expiry is the planned freeze end plus a short buffer. No acceptance is open ended. When it expires, someone must either fix, re-accept with a new reason, or escalate. That is how acceptances survive the freeze without becoming permanent.

Rule 3: the approver matches the risk. A simple ladder works:

The bottom row is your floor. If you cannot patch, SP 800-40 Rev. 4 gives you emergency mitigation and avoidance: disable the feature, restrict exposure, or take the component out.

CSF 2.0 ID.RA-07 asks that exceptions are recorded and tracked. Put expiries on a calendar, send owners a weekly list of what expires in the next 30 days, and show the count on the executive page. For the wider framing of how much risk the company is willing to carry, see how to write a security risk appetite statement.

How do you show the executive team the exposure the freeze creates?

Executives approve freezes in units of headcount and dollars. Your job is to translate the freeze into units of risk, so the decision is made with both sides visible.

1. Lead with the floor. "KEV listed vulnerabilities in exposed and tier 1 products are still handled to our normal targets. That will not change."
2. Then show what the company is now carrying: active acceptances by tier with their expiry profile, tier 1 changes shipping without full design review, and paused SAMM practices.
3. Then show slippage within limits: findings past freeze targets by tier and severity, in the matrix shape from SP 800-40 Rev. 4 section 3.6, which warns that a raw percentage unpatched means little unless you know which assets.
4. Then show what would trigger a request to lift the freeze for one role, for example a tier 1 KEV finding missing its target, or a customer commitment at risk.
5. Tie it to governance language. CSF 2.0 GV.RR-01 places accountability for cybersecurity risk with organisational leadership, and GV.RR-03 asks for resources commensurate with the strategy. The executive page is how leadership exercises that accountability during the freeze.

Avoid presenting the freeze as hours. Lost hours invite "find efficiencies"; "41 accepted risks expire in March and tier 1 design reviews have stopped" invites a decision.

If you want a per finding view of where research time goes, cut the hours your team spends researching vulnerabilities covers it, and run AppSec at one security engineer per hundred developers covers the steady state staffing model. This post is the temporary version.

What do you restart first when the freeze lifts?

The restart order should be decided now, while the reasons for each pause are fresh. A default order:

1. Expired and expiring acceptances on tier 1 and 2. Work through them before anything new. Each one is either fixed, re-accepted with a fresh reason, or escalated.
2. Design reviews for tier 1 changes that shipped during the freeze. Prioritise anything that changed authentication, authorisation, data handling or exposure.
3. Threat models for tier 1 products that had none or had stale ones.
4. The backlog of tier 2 critical and high findings that slipped past freeze targets.
5. Security champion training, because the delegated work during the freeze will have shown where engineering teams need help.
6. Program improvement work that was paused, starting with whatever would most reduce the load if another freeze arrived.

Then hire into the gap the freeze exposed, not into the old job description.

How Safeguard does this

Everything above works with spreadsheets, a ticket tracker and your existing scanners. If you run Safeguard, here is how the same plan maps onto the product, using only what Safeguard's offering documentation and docs.safeguard.sh describe. Commands and screens are as the docs show them; we did not run the snippets for this post.

1. Connect repositories and scan in CI

Safeguard's software composition analysis and vulnerability management (GA) builds the dependency inventory for each project and matches it against vulnerability data, including CISA KEV. The CI/CD integration runs one Safeguard CLI (GA) step in your pipeline. Per the docs, you create a secret key under Settings, Developer with the scans:trigger and scans:read scopes, store it as SAFEGUARD_API_KEY in your CI, and add the step from your CI system's guide. The docs list guides for GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Jenkins and Azure Pipelines, plus a generic shell step for other systems:

curl -fsSL https://cli.safeguard.sh/install | bash
SAFEGUARD_API_KEY=... safeguard ci scan --wait --fail-on critical \
  --repository-url "$REPO_URL" --branch "$BRANCH" --commit "$COMMIT"

Per the docs, --local scans on the runner so only results leave it. Start with tier 1 repositories.

2. Rank findings by reachability, EPSS and KEV

Reachability analysis and prioritisation (GA) combines call path reachability with EPSS, KEV, runtime context and business context into a single priority score per finding. The docs describe four reachability classes: reachable, conditionally reachable, unreachable and unknown. Unknown is treated conservatively as potentially reachable and is not suppressed. Business context lets you declare which assets are regulated or customer facing, so findings there rank higher; that is where your tier list goes.

The Vulnerabilities tab has Priority and Reachability columns, and the docs show filters such as env:production reachable:true kev:true, which is close to the "cannot pause" row of your plan. Analysis quality varies by language, and the docs list support per language; check yours before you rely on it to defer work.

3. Write the freeze rules as policies and gates

Policies, gates and guardrails (GA) are how the delegated work in Step 5 becomes enforceable. In Safeguard, policies evaluate your projects and generate findings, and gates are the checkpoints that enforce them. The docs walk through creating a policy:

1. Go to Settings, Policies.
2. Click Create Policy.
3. Define conditions using the visual builder or YAML.
4. Set severity and actions.
5. Save and enable.

Conditions in the docs include severity, CVSS, EPSS, license, component age and maintenance status, with templates such as "No Critical Vulnerabilities". Safeguard also supports creating policies from plain English prompts (GA), which helps when an engineering director needs to read the freeze rules back and agree.

Each policy has one action, and per the docs it decides what a failed policy does to the gate:

• Block: the gate fails.
• Warn: the gate passes, with a warning naming the policy.
• Notify: the gate passes, and Safeguard sends a notification to your workspace's configured channels: the in app bell, connected chat integrations, and email according to each person's preferences.

That maps neatly onto tiers. A reasonable freeze setup is Block for critical vulnerabilities on tier 1, Warn on tier 2, and Notify on tier 3, with the KEV rule on Block everywhere it applies. Per the docs, Notify fires when a policy starts failing and again when it finds new matches, not on every evaluation, which spares a small team repeat alerts.

To make CI fail on a gate rather than on raw severity, the docs show:

safeguard ci scan --wait --fail-on-gate <gate name or id | all>

It exits 0 when the gate is Passed or Warning, and non-zero when the gate is Failed, Error or Not evaluated. One honest detail from the docs: policy outcomes are turned on per workspace by Safeguard. If your workspace does not show an Outcome column on the Gates and Policies tables, ask your Safeguard contact to turn it on. The docs also say SAST findings are scanned and shown but are not part of --fail-on yet.

4. Record accepted risk as exceptions with an expiry

The risk acceptance record in Step 6 maps onto Safeguard's policy exceptions. Per the docs, a requester clicks Request Exception, selects the policy and finding, provides a business justification, sets an expiration date and submits it for approval. Approvers are notified, review and decide, and an audit trail is recorded. Approval runs through this exception path; it is not a separate gate action.

Set the expiry to your freeze end plus a buffer. The docs list reporting on exception history and violation trends, which supports the "recorded and tracked" outcome in CSF 2.0 ID.RA-07.

5. Give engineering owners pull requests, not tickets

Autonomous remediation (GA) uses Griffin to open fix pull requests. It ships switched off: every remediation category defaults to Manual, and nothing is applied until the master Autonomous Remediation toggle is enabled. The AI Remediate docs describe the flow as analysis, solution generation, impact assessment, pull request creation and validation, with breaking change detection that classifies each change as Safe, Minor, Major or Critical.

The docs describe three ways to use it:

1. Single vulnerability: open the vulnerability, click AI Remediate, review the proposed changes, click Create Pull Request.
2. Bulk: select vulnerabilities, click AI Remediate Selected, review, and create pull requests, one per repository.
3. Page level: from the Vulnerabilities page, click AI Remediate, review the plan, approve and create pull requests.

Settings under Settings, AI Remediate include Require Approval, Test Integration and Breaking Change Policy. A cautious freeze setup keeps Require Approval on, turns on Test Integration, and starts with bulk pull requests on tier 2 and 3 repositories whose owners agreed to merge them. Every pull request still needs a human reviewer.

6. Route work to the people who own it

Notifications and ticketing (GA) cover Jira and Slack, among others. Per the Jira docs, the Jira card under Integrations, Notification tab connects Safeguard to one Jira Cloud project. Safeguard creates issues for the findings and work you send to Jira, updates them, and moves them through your workflow using the status mapping you set. It checks the issues it created every few minutes to pick up changes made in Jira. Jira Data Center is not supported yet, and Atlassian API tokens expire, so put the token expiry on the same calendar as your acceptances.

The Slack card sends new findings, scan results and alerts to a channel through a bot token or an incoming webhook; the docs' least privilege setup uses only chat:write and channels:read. One channel per tier works well, and it is where the Notify action lands.

7. Report exposure on a schedule

Safeguard's dashboards and scheduled tasks (GA) support the monthly executive page. The analytics docs describe built in dashboards including a Program Overview (open critical and high findings by environment, KEV findings in production, time to remediate), a Vulnerability Backlog (open findings by severity, priority and reachability, with aging buckets), and a Compliance view that includes exceptions open and expiring. They also describe email scheduled reports driven by any dashboard, including a weekly executive summary, shipped as PDF.

Use the dashboards for the numbers and keep the narrative yours.

8. Ask questions from an AI assistant

Per the policy outcomes docs, Safeguard's MCP server (GA) has read only tools for gate outcomes, policy outcomes and evaluation history, when policy outcomes are on and your MCP access settings allow them. An engineer can ask an assistant which tier 1 gates failed this week.

What Safeguard does not do

• It does not replace the engineer you lost. Policies, prioritisation and fix pull requests reduce the routine load, but judgement calls about exploitability in context, design trade offs and risk acceptance stay with people. We make no claim about hours saved; measure your own before and after.
• It does not threat model for you. Design review and threat assessment for tier 1 changes remain human work. Safeguard can show you what is in a product and what is vulnerable; it does not decide whether a new data flow is safe.
• It does not answer customer security reviews on its own in this flow. Questionnaires and customer calls need a person who knows your architecture and your contracts. Keep the approved answer library from Step 7.
• It does not merge or ship fixes without people. Autonomous remediation ships switched off with every category on Manual. Even when enabled, every fix pull request should be reviewed and merged by the owning team, and tests still matter.
• It does not decide your tiers, targets or acceptances. Business context and policies encode decisions you make; the product does not know which customer contract names which control.
• Reachability is not proof of safety. The docs say it is weakest for reflection, dynamic dispatch, data driven vulnerabilities and unenumerated configuration paths, and support varies by language.
• Some flows depend on workspace settings. Policy outcomes, and the CI and MCP features built on them, are turned on per workspace by Safeguard. Jira Data Center is not supported yet.

Common mistakes

1. Treating the freeze as permanent capacity loss without saying so. If you never write an end date and a restart order, the "temporary" plan becomes the program.
2. Spreading the remaining people evenly across products. Even coverage means thin coverage on tier 1. Cover by tier.
3. Delegating without an exception path. Engineering teams that cannot meet a rule and have no legitimate way to say so will work around it. Give them the exception form and the approver.
4. Letting teams approve their own exceptions. The approver should not be the person who benefits from the delay.
5. Open ended acceptances. "Accepted" without an expiry is how a freeze decision becomes a finding in next year's audit.
6. Reporting hours instead of exposure. Executives can trade hours for money; they need to see the risk to decide.
7. Accepting KEV listed findings on exposed products. That is the floor. Mitigate or avoid, using SP 800-40 Rev. 4's emergency mitigation scenario if a patch is not possible.
8. Turning on every automation at once. Start with Notify, then Warn, then Block on tier 1.
9. Forgetting the restart. Without a restart order, the first quarter after the freeze is spent rediscovering what was paused.

FAQ

How do I keep application security running during a hiring freeze?

Plan for two quarters. Sort the work into stop, automate, delegate, accept or keep, tier products by exposure and data, keep KEV handling unchanged, record every accepted risk with an owner and expiry, and report exposure monthly.

What AppSec work should never pause during a freeze?

Response to known exploited vulnerabilities in exposed and tier 1 products, release gates on tier 1 products, customer contract commitments, incident response support, and anything you have already told an auditor or regulator is in place.

How do I document risk acceptance for vulnerabilities I cannot fix?

Use NIST SP 800-40 Rev. 4's four risk responses, choose "accept", and record the finding, the reason, the existing controls you rely on, an owner, an approver, an expiry date and the events that reopen the decision early. SSDF RV.2.2 and CSF 2.0 ID.RA-07 support the same practice.

Who should approve risk acceptances during a freeze?

Match the approver to the risk: engineering managers for low risk on internal systems, a director plus the AppSec lead for mid range risk, and the CISO for anything critical or high on tier 1. Nobody should approve an exception for their own team's work.

How do I tell the board about a security hiring freeze?

Show the floor that has not moved, the risk now carried, slippage by tier and severity, and what would trigger a request to lift the freeze for one role, framed by CSF 2.0 GV.RR-01 and GV.RR-03.

Can developers take over AppSec work during a freeze?

Some of it: merging dependency upgrades, fixing findings that fail automated policies and requesting exceptions. Not approving their own exceptions or owning tier 1 threat models. SSDF PO.2.1 supports deliberate, written role changes.

Does BOD 26-04 apply to a private SaaS company?

No. BOD 26-04 directs US federal civilian agencies. It is a useful model because its four factors (public exposure, KEV status, exploit automation and technical impact) are a defensible way to rank vulnerabilities, and federal customers may recognise it.

How do I prioritise vulnerabilities with fewer people?

Start with KEV, then exposure and reachability, then EPSS, then severity, filtered by product tier. That ordering puts known exploitation and exposed paths ahead of raw CVSS scores.

The fixes that pull the most weight during a freeze are the ones that do not need your scarce engineers to write them. The section below is Safeguard's standard description of how fixes move from a known safe version, or from no fix at all, into your builds.

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 first demo is a real Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. During a freeze this is the shape of help an engineering owner can use on a tier 2 repository without waiting for the security team, while the approval step keeps a person in charge.

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

The second demo connects Claude to the Safeguard MCP server with OAuth and shows you choosing which tools Claude can use. For a CISO running a thin team, the value is that a remaining engineer can ask questions about findings and gate outcomes from an assistant, within the access you set, instead of building a report by hand.

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

Quick check

To try the flow on your own repositories, download Safeguard at safeguard.sh/download and read the docs at docs.safeguard.sh/docs.

Sources

• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning (PDF)
• NIST SP 800-40 Rev. 4 publication page
• NIST SP 800-218, Secure Software Development Framework (PDF)
• NIST SP 800-218 publication page
• NIST Cybersecurity Framework 2.0, CSWP 29 (PDF)
• NIST Cybersecurity Framework
• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA Secure by Design
• FIRST Exploit Prediction Scoring System (EPSS)
• OWASP SAMM: The Model
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: AI Remediate
• Safeguard docs: Jira integration
• Safeguard docs: Slack integration
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Analytics and Dashboards
• Safeguard docs: CI/CD Integration

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