No AppSec team? Where a mid-market Head of IT should start

If you run IT at a mid-market company that does not sell software, and nobody owns application security, start with a list, not a tool. Write down every application your company builds, customizes or pays someone else to build, who holds the code, and which ones face the internet. Then scan the dependencies of everything you own, test the internet facing apps you are authorized to test, set written patch rules that put known exploited vulnerabilities first, and put the same expectations into every agency contract and vendor review.

This guide is written for a Head of IT or IT Director at a manufacturer, distributor, logistics firm, regional services business or similar company where software is how the business runs, not what it sells. Most of it works with whatever tools you already have. The Safeguard part is marked, and it comes late.

Key takeaways

• Your first deliverable is an application inventory, not a scanner. Include the customer portal, the e-commerce site, ERP and CRM customizations, internal tools, integration scripts and anything an agency built for you.
• Get the code and the deploy keys back. If an agency holds the only copy of your portal's repository, you cannot scan, patch or move it.
• Tier the apps by exposure and data. An internet facing portal with customer records is tier 1; an internal report tool is tier 3.
• Dependency scanning gives the most coverage per hour, because most of the code in a modern web app is open source.
• Patch by risk, not by score. CISA's Known Exploited Vulnerabilities catalog comes first, then internet exposure, then EPSS probability, then severity. BOD 26-04 binds federal agencies, not you, but its four factors are a good model.
• Test what faces the internet, only with written authorization. Dynamic testing of your own portal is reasonable; testing a vendor's hosted service without permission is not.
• Write rules down and allow exceptions with an expiry. Rules with no exception path get ignored; exceptions with no expiry become permanent.
• Ask vendors the same questions you would ask yourself. CISA's Secure by Demand guide gives software buyers a ready set of questions.
• Safeguard capabilities covered, all GA: software composition analysis and vulnerability management with EPSS and KEV, SBOM generation, reachability analysis and prioritisation, policies, gates and guardrails with plain English policy creation, autonomous remediation (ships switched off), DAST, TPRM, the Portal free entry tier, the Safeguard CLI and local runner, notifications and ticketing, and dashboards.

The situation

The trigger is rarely a breach. More often it is a form. A large customer sends a security questionnaire with a section headed "Secure software development" and asks whether you scan your applications, how fast you patch critical vulnerabilities, and whether you can provide a software bill of materials for the portal they log into. The cyber insurance renewal asks whether your public web applications are tested and how often. Or the CEO reads about a peer company whose customer portal leaked records through an old library, and asks you on Monday whether that could happen here.

You are the obvious person to answer, because there is nobody else. Your team runs the network, endpoints, identity, the ERP, the help desk and backups. Two or three developers maintain the portal and integrations, and an outside agency that built the e-commerce site still pushes changes when asked. Nobody's job description says "application security."

A bad week looks like this. The questionnaire is due Friday. You do not know how many applications the company runs. The agency says the portal "uses modern frameworks" but cannot name the library versions in production. You can answer "no" honestly, "yes" dishonestly, or ask for an extension. This guide gets you to an honest "yes, and here is how" within a quarter.

What is at stake is concrete. Portals and e-commerce sites hold customer data and payment flows, and integration scripts often hold ERP credentials. Known exploited vulnerabilities in popular web components are scanned for automatically, so an outdated framework on an internet facing server is an easy way in. You do not need an AppSec team to close most of that exposure. You need a list, a routine and a few written rules.

The rules and standards behind it

None of the documents below are law for most mid-market companies. They are what customers, auditors and insurers tend to point to when they ask whether you have a reasonable program, and they give you a structure you can defend. This is not legal, regulatory or audit advice; where a contract or regulator binds you, read that text first.

CIS Controls v8.1: Controls 2, 7, 15 and 16, by Implementation Group

The CIS Critical Security Controls are written for your situation: they sort safeguards into Implementation Groups (IGs) so a company with a small IT team knows what to do first. CIS says every enterprise should start with IG1, which it calls essential cyber hygiene, and describes the typical IG1 enterprise as small to medium sized with limited IT and cybersecurity expertise. An IG2 enterprise employs people responsible for managing and protecting IT infrastructure and supports several departments with different risk profiles. Most mid-market companies with a Head of IT sit between the two, and should finish IG1 before reaching for IG2.

Four Controls matter here, in CIS's own framing:

• Control 2, Inventory and Control of Software Assets. Actively manage all software on the network so only authorized software runs. Your own applications belong on that list, not just the purchased software on laptops.
• Control 7, Continuous Vulnerability Management. Keep a plan to continuously assess and track vulnerabilities on all enterprise assets and shrink the attacker's window of opportunity.
• Control 15, Service Provider Management. Evaluate providers who hold sensitive data or run critical IT platforms or processes. The agency that maintains your portal is one.
• Control 16, Application Software Security. Manage the security life cycle of software that is developed in house, hosted or acquired. Note the scope: CIS does not limit this Control to software companies. If you commissioned it or host it, it is in.

NIST Cybersecurity Framework 2.0: inventory and supply chain

If your board or a customer uses NIST CSF 2.0 language, three outcomes map to this work. ID.AM-02 expects inventories of the software, services and systems the organization manages. GV.SC-04 expects suppliers to be known and prioritized by criticality. GV.SC-05 expects supply chain security requirements to be established, prioritized and written into contracts and other agreements with suppliers. Your agency, your SaaS vendors and the open source components inside your apps all sit under those lines.

NIST SP 800-218: the SSDF for software you build or commission

The Secure Software Development Framework (SSDF), published in February 2022, groups secure development practices into Prepare the Organization (PO), Protect the Software (PS), Produce Well Secured Software (PW) and Respond to Vulnerabilities (RV). NIST notes that software purchasers can use its vocabulary when talking to suppliers, which is exactly your position with an agency. Four tasks are directly useful:

• PO.1.2's examples include a process for handling requests for exceptions to security requirements, with periodic review of approved exceptions. That is your exception form.
• PO.1.3 says to communicate security requirements to third parties who supply software components, and its first example is to put a core set of requirements into contracts and agreements.
• PW.4.1 says to acquire and maintain well secured third party software, which in practice means knowing which open source components are in use and keeping them current.
• RV.1.1 says to gather vulnerability information from public sources and others about the software and the third party components it uses, and investigate credible reports.

CISA KEV, BOD 26-04 and EPSS: what to patch first

CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with evidence of exploitation in the wild. It is the single most useful filter for a small team: if a component in an internet facing app is on KEV, it goes to the top.

Binding Operational Directive 26-04, issued on 10 June 2026, revoked BOD 22-01 and BOD 19-02 for US federal civilian agencies. It sets remediation urgency from four variables: whether the asset is publicly exposed, whether the CVE is on KEV, whether an adversary can automate every step of exploitation, and whether exploitation gives partial or total control. It does not bind private companies, and the directive says it does not apply to contractors unless their procurement contract directs it. It is still a sound, public model for your own patch rules.

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, updated daily and free to use. It is a good tiebreaker for the long tail of findings that are not on KEV.

OWASP Top 10 and ASVS: what "tested" means

When a questionnaire asks whether your web applications are tested "against common vulnerabilities," it usually means the OWASP Top 10. The 2025 edition puts Broken Access Control at A01 and lists Software Supply Chain Failures at A03, a reminder that outdated components are an application security problem, not just an IT patching problem. When a customer wants more depth, the OWASP Application Security Verification Standard (ASVS, now at 5.0.0) gives testable requirements for web application security controls.

CISA Secure by Demand: for the software you buy

Most of the software your company runs, you buy. CISA's Secure by Demand guide is written for software customers and points out that due diligence usually checks a vendor's enterprise security (its own infrastructure) while saying little about product security (whether what it ships resists attack). Its questions cover SSO at no extra cost, MFA by default, eliminating whole classes of vulnerability, timely CVE records with accurate CWE fields, a public vulnerability disclosure policy, an SBOM, and how patches reach customers.

SBOMs: CISA's 2026 minimum elements

A software bill of materials is the ingredient list for an application. CISA published updated SBOM minimum elements in 2026, replacing the 2021 NTIA list as the reference for what a useful SBOM contains. If a customer asks for an SBOM of your portal, produce it in a standard format (SPDX or CycloneDX) and keep it current with each release.

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

The steps below assume a few hours a week of your time, a few hours a week from one developer, and no new budget yet. Each step names an output you can show someone.

Step 1. Build the application inventory (week 1 to 2)

Start with a spreadsheet. Ask finance for every software development invoice in the last three years, ask your developers for every repository they push to, and check DNS for every public hostname. Then fill in one row per application:

Expect surprises: an order integration script holding ERP credentials on a forgotten server, a marketing site from a second agency, a plant web app a former employee wrote.

Output: a list you can hand to a customer's questionnaire or an auditor, with an owner on every row.

Step 2. Get the code and the keys back (week 2 to 4)

For each row where "where the code lives" is not your own Git host, fix it. Ask the agency to mirror the repository into an organization you own, or to add your account as an owner. Make sure you hold the production deploy credentials and the cloud account, not just the agency. Check the contract for who owns the code; most development contracts assign it to the client, but confirm.

This is the step that most often blocks a mid-market AppSec program, and it has nothing to do with security tools. If you cannot see the code, you cannot know what is in it.

Output: every tier 1 and tier 2 application in a repository your company controls.

Step 3. Tier the applications (week 3)

Use two questions: is it reachable from the internet, and does it hold data that would hurt customers or the business if exposed? A simple grid works:

Anything with service credentials to the ERP or the identity provider moves up a tier, because a compromise there spreads. Keep the tier on the inventory sheet.

Output: a tier on every row, agreed with the business owners.

Step 4. Scan dependencies for everything you own (week 3 to 6)

Software composition analysis (SCA) reads each repository's dependency files (lockfiles, requirements files, pom.xml, .csproj and similar), lists every component including transitive ones, and matches them against vulnerability databases. For a team with no AppSec staff it is the highest value scan: fast, lower noise than code analysis, and it covers the open source code that makes up most of a web app.

Run it on tier 1 first. Free open source scanners and your Git host's dependency alerts are fine for a first pass. Whatever you use, make it produce an SBOM in SPDX or CycloneDX.

Output: an SBOM and a findings list per tier 1 and tier 2 application.

Step 5. Write patch rules that put exploitation first (week 5)

You will find more vulnerabilities than you can fix. Decide in writing which ones get fixed and how fast. Here is a starting template, adapted from the BOD 26-04 factors for a private company. The targets are illustrative; set your own.

Two rules make the table work. First, an exception path: anyone who cannot meet a target can ask for an extension, with a reason, a compensating control and an expiry date, approved by the business owner and you. Second, an end of life rule: a framework or runtime that no longer gets security updates is itself a finding, with a replacement plan and date.

Output: a one page patch standard, signed by the CEO or COO, and an exception form.

Step 6. Test what faces the internet, with authorization (week 6 to 10)

Dependency scanning does not find a broken login flow or a page that shows another customer's orders. Dynamic application security testing (DAST) probes the running app from the outside, the way an attacker would, and catches classes like broken access control, injection and misconfiguration from the OWASP Top 10.

Rules for doing this safely:

1. Test only applications you own or have written permission to test. For an agency built portal hosted in your cloud account, you own it. For a vendor's hosted SaaS, you do not; ask for their test reports instead.
2. Start with a staging copy where one exists. If you test production, schedule it, tell the business owner, and keep the test account away from real customer data.
3. Use dedicated test accounts at each role level, so access control checks can compare what each role can see.
4. Once a year, for tier 1, buy a human penetration test. An annual test of the customer portal is a common customer and insurer expectation, and a tester finds business logic flaws that automated tools miss.

Output: a dated test report for each tier 1 application, with findings in the same tracker as the dependency findings.

Step 7. Put the rules into the build (week 8 to 12)

Once the patch standard exists, make the build enforce the floor. A check in the CI pipeline that fails the build when a new dependency brings in a KEV listed or critical vulnerability stops the backlog from growing while you work it down. Start in warn only mode for two weeks so developers see what would fail, then switch tier 1 to blocking. Keep the exception path from Step 5 as the only way past a block.

If developers deploy by copying files to a server, that is a finding in itself. A basic build, scan, deploy pipeline is worth more than any single security tool.

Output: a pipeline check on every tier 1 repository, with a documented exception route.

Step 8. Put security into agency and contractor contracts (renewal by renewal)

For each development agency or contractor, add these clauses at the next renewal or statement of work. They follow SSDF PO.1.3, CSF 2.0 GV.SC-05 and CIS Control 15; have your counsel adapt the wording.

• Code is stored in a repository the company owns, and the company holds owner access and deploy credentials.
• The agency keeps third party components current and fixes known exploited vulnerabilities within the company's patch standard.
• The agency provides an SBOM in SPDX or CycloneDX with each release.
• The agency runs dependency scanning on every change and shares results.
• Security defects found by the company or a tester are fixed at the agency's cost within agreed times.
• The agency notifies the company within an agreed time of any security incident affecting the company's code, credentials or environments.
• Production access is through the company's identity provider, with individual accounts and MFA, and is removed at contract end.

Output: a standard security exhibit attached to every development contract.

Step 9. Ask your software vendors better questions (at each renewal)

For the software you buy, use the Secure by Demand questions rather than a 300 line generic questionnaire. Five questions do most of the work for a mid-market buyer:

1. Do you support standards based single sign on at no extra cost, and is MFA on by default?
2. Do you file timely CVE records for your product with accurate CWE fields, and how do you notify customers?
3. Do you have a public vulnerability disclosure policy?
4. Can you provide an SBOM for the version we run?
5. How are security patches delivered, and how quickly after a fix exists?

Add your normal contract asks (breach notification time, independent reports, data deletion at exit) and record the answers against the vendor. Start with vendors that hold customer data or connect to your ERP. A vendor that cannot answer is a risk to name to the business owner, not a reason to cancel on the spot.

Output: answers on file for every vendor that holds customer data or runs on your network.

Step 10. Report one page a month (from month 2)

Your CEO does not want a findings export. Give them one page:

The last line is the important one. Every month, ask for one decision: approve the pen test budget, accept a specific exception, move an end of life app onto the replacement plan.

Output: a monthly page that shows the program working and the risk you still carry.

What counts as an application for a company that does not sell software?

Anything your company runs that someone wrote code for, on your behalf or with your customizations. That includes the obvious (customer portal, e-commerce site, B2B ordering, mobile apps) and the less obvious: ERP and CRM customizations and extensions, integration scripts and middleware, scheduled jobs that move files to partners, internal web tools, low code apps, the marketing site and its plugins, and anything a former employee built. It excludes off the shelf software you run unchanged, which belongs on the software inventory and in vendor review, not in your AppSec program.

What should you do first if you only have a few hours a week?

Steps 1, 3 and 4, in that order, for tier 1 only. An inventory with tiers, plus a dependency scan and an SBOM for each internet facing app with customer data, answers most of a questionnaire's "secure development" section honestly and shows where the urgent exposure is. Then write the patch standard. For a deeper look at ranking with KEV and EPSS on a small team, see how to prioritize CVEs with a small IT team.

Do you need to hire an AppSec engineer, or can IT own this?

IT can own the program at this stage. What IT should not own is fixing application code; that stays with whoever builds the app, staff or agency. The Head of IT owns the inventory, the rules, the tools, the contracts and the report; developers fix findings within the targets. Consider a dedicated hire when tier 1 apps outgrow what one person can review in a week, when a customer or regulator requires a named security role, or when you start selling software. Until then, an outside reviewer for the annual tier 1 test is usually a better use of budget. Our posts on when to hire a first AppSec engineer and who owns security with no security team go further.

How do you handle apps built by an agency or contractor?

Treat the agency as a supplier under CIS Control 15 and CSF 2.0 GV.SC, and treat the code as yours. Get the repository into an organization you own (Step 2), scan it yourself rather than relying on the agency's word (Step 4), and add the security exhibit at the next renewal (Step 8). If the agency will not give you access, scan what you can see (the deployed site from outside, the dependency files they send) and raise the access question with the business owner as a risk. A scanner that runs inside the agency's environment and returns only results can be a workable compromise.

How do you answer the customer questionnaire or insurance application honestly?

Answer what is true today and say what is planned with dates. "We maintain an inventory of applications; internet facing applications are scanned for vulnerable dependencies on every change; known exploited vulnerabilities are remediated within two weeks; an annual third party penetration test is planned for Q1" is a stronger answer than an unqualified "yes" that falls apart on a follow up call. Keep a library of approved answers, signed off by you, so sales does not improvise. Never claim a certification, test or control you do not have.

How Safeguard does this

Everything above works with a spreadsheet, your Git host and free scanners. If you use 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. Start free on one repository

The Portal free entry tier (GA) lets you sign up for free and scan one existing repository plus one open source repository from GitHub, GitLab or Bitbucket, one project per month, with software composition analysis only. That is enough to run Step 4 on your most important tier 1 app and see what the findings and SBOM look like before you commit to anything.

2. Scan every repository in CI

Safeguard's software composition analysis and vulnerability management (GA) builds the full dependency inventory per project, including transitive dependencies, matches it against vulnerability data enriched with EPSS and CISA KEV, and produces SBOMs (GA) in SPDX and CycloneDX. 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:

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.

3. Rank findings the way your patch standard does

Reachability analysis and prioritisation (GA) combines reachability, EPSS and KEV, runtime context and business context into one ranked backlog. The docs describe four reachability classes (reachable, conditionally reachable, unreachable, unknown) and treat unknown as potentially reachable. Business context is where your tiers go. The docs' filter env:production reachable:true kev:true is close to the top row of your patch table. Quality varies by language; check yours.

4. Turn the patch standard into policies and gates

Policies, gates and guardrails (GA) make Step 7 enforceable. Policies evaluate projects and generate findings; gates are the checkpoints that enforce them. The docs walk through creating a policy under Settings, Policies: click Create Policy, define conditions with the visual builder or YAML, set severity and actions, then save and enable. Conditions include severity, CVSS, EPSS, license, component age and maintenance status. You can also create policies from plain English prompts (GA), which helps when the business owner needs to read the rule back.

Each policy has one action. Per the docs, Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification to your workspace's configured channels. A sensible start is Notify everywhere for two weeks, then Block for KEV and critical findings on tier 1 and Warn on tier 2. To fail CI on a gate rather than raw severity, the docs show:

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

Approval runs through exceptions, not through a gate action. Per the docs, a requester clicks Request Exception, selects the policy and finding, gives a business justification, sets an expiration date and submits it for approval; approvers are notified and an audit trail is kept. That is the exception form from Step 5, with the expiry built in.

5. Give developers and the agency pull requests, not tickets

Autonomous remediation (GA) uses Griffin to open fix pull requests that move a vulnerable dependency to a safe version. It ships switched off: every remediation category defaults to Manual, and nothing runs until the master Autonomous Remediation toggle is enabled. The AI Remediate docs describe single, bulk (one pull request per repository) and page level flows, with breaking change detection. For a company where the agency writes the code, a pull request against the repository you own is a cleaner handoff than a spreadsheet of CVEs; the agency still reviews, tests and merges.

6. Test the internet facing apps you own

DAST (GA) is Safeguard's first party dynamic testing. Per the application security testing docs, it sends safe, non destructive requests to a running app and looks for issues such as missing security headers, injection classes and misconfigurations. The safety controls match the authorization rule in Step 6:

1. Add the target as a Safeguard DAST integration, the same way you add a repository.
2. Verify ownership with a DNS TXT record, an uploaded file, a meta tag or a verified email domain. Until then, active checks cannot run.
3. Set the scope. Every request is checked against an allow listed host and path scope, and out of scope requests are blocked and logged.
4. Choose a safety mode: passive, safe_active or authenticated_safe_active for normal use. Rate limits per target are mandatory and configurable.
5. Review findings in the same findings view as dependency results. Every DAST request and finding change goes into an audit trail.

The docs also say detection depth expands over time. Keep the annual human penetration test for tier 1.

7. Scan agency code where it lives

If the agency will not move code out of its environment, the Safeguard CLI and local runner (GA) offer a middle path. Per the docs, the runner is part of the CLI: once someone signs in, the machine polls the platform for scan jobs, runs each one locally and uploads only the resulting SBOM and findings, never the source code. All traffic is outbound HTTPS the runner opens; nothing connects to it. The docs show the install and first run:

curl -fsSL https://cli.safeguard.sh/install | bash
safeguard

Then type /login, approve the session in the browser, and the runner starts. For an unattended machine, the docs show safeguard runner start --workspace ./path/to/repo. The agency runs it on its side; you see the findings.

8. Ask vendors for SBOMs and track supplier risk

TPRM (GA) is Safeguard's third party risk product: onboard vendors, request SBOMs from them, score and continuously monitor supplier risk, and apply policies and gates to what they send. Per the SBOM requests docs, you open the vendor, click Request SBOM, select the products, choose a request template, set a deadline and send; Bulk Request does the same across several vendors. The standard template asks for SPDX or CycloneDX. Requests are tracked through Sent, Viewed, In Progress and Submitted. That is Step 9 with the SBOM answer checked rather than filed.

9. Route work and report monthly

Notifications and ticketing (GA) cover Slack, Microsoft Teams and Jira, among others. Per the Jira docs, Safeguard connects to one Jira Cloud project, creates issues for the findings you send and syncs status through a mapping you set; Jira Data Center is not supported yet. Dashboards (GA) live under Home, Dashboards; the docs describe a Program Overview that includes KEV listed findings in production, a Vulnerability Backlog with aging buckets, and scheduled reports by email as PDF, such as a weekly executive summary.

What Safeguard does not do

• It does not know about applications you never connect. It analyses the repositories, images and SBOMs you give it. The forgotten plant web app or the second marketing agency is your Step 1.
• It does not get you access to code you do not control. If an agency holds the only copy of your portal's repository, no scanner fixes that. The contract does.
• It does not replace a human penetration test or design review. A tester finds business logic flaws that automated testing misses.
• It does not test vendors' hosted services for you. You can only test what you own or are authorized to test. For SaaS you buy, use TPRM, SBOM requests and the vendor's own reports.
• It does not merge or deploy fixes on its own by default. Autonomous remediation ships switched off with every category on Manual, and every pull request should be reviewed and tested by whoever owns the code.
• It does not decide your tiers, targets or acceptances. Policies encode decisions you make. Signing the patch standard and approving exceptions stay with you and the business owners.
• Reachability is not proof of safety. Support varies by language, and unknown reachability is treated as potentially reachable, so some findings will stay on the list.
• It is not your server and endpoint patching tool. This post covers the software you build or commission. Windows updates, firewall firmware and laptop patching stay in your existing IT tooling.

Common mistakes

1. Buying a scanner before writing the list. You scan the repositories you know and miss the ones that matter.
2. Accepting "the agency handles security." Ask for the SBOM and the scan results. If they cannot produce them, they are not handling it.
3. Scanning without a patch standard. A thousand findings with no rule for which ones matter produces paralysis, not progress.
4. Sorting only by CVSS. A critical score in an internal tool matters less than a high score on KEV in your customer portal.
5. Blocking builds on day one. Developers will route around a gate that appears overnight. Warn first, then block tier 1.
6. Exceptions with no expiry. "Accepted" without a date is how a temporary decision becomes next year's audit finding.
7. Testing a vendor's service without permission. It can breach your contract and, in some cases, the law. Ask for their reports.
8. Forgetting end of life frameworks. An app on a runtime with no security updates will keep producing findings you cannot fix by upgrading a library.
9. Overclaiming on the questionnaire. An unsupported "yes" costs more trust than an honest "planned for Q1."

FAQ

Where should a Head of IT start with application security?

With an inventory of every application the company builds, customizes or commissions, who holds its code and which ones face the internet. Then tier them, scan tier 1 dependencies, and write a patch standard that puts known exploited vulnerabilities first.

Is application security IT's job if we do not sell software?

Owning the program can be. Fixing application code belongs to whoever writes it, staff or agency. IT owns the inventory, the rules, the tools, the vendor and agency contracts and the report to leadership.

Do I need an SBOM if I do not sell software?

Customers ask for one for portals they log into, and it is the fastest way to answer "are we affected?" when a component vulnerability makes the news. Generate one per application, in SPDX or CycloneDX, with each release.

How fast should a mid-market company patch critical vulnerabilities?

Set your own targets in writing. A defensible start is days to mitigate and two weeks to fix KEV listed issues in internet facing apps, 30 to 45 days for other critical and high findings in tier 1, and longer for lower tiers.

Does CISA BOD 26-04 apply to private companies?

No. It directs US federal civilian agencies. It is a useful public model because its four factors (public exposure, KEV status, whether exploitation can be automated, and technical impact) are a defensible way to rank findings.

How do I make an agency fix security issues in code they wrote?

Write it into the contract: repository ownership, a patch standard, SBOMs with each release, dependency scanning, fix times for security defects and incident notification. Then send findings as pull requests or tickets against code you control.

Should we run DAST against our production website?

Only on applications you own or are authorized to test, ideally against staging first. If you test production, schedule it, inform the business owner and use test accounts away from real customer data.

Which CIS Controls cover application security?

Control 16, Application Software Security, which covers software developed in house, hosted or acquired. Controls 2 (software inventory), 7 (vulnerability management) and 15 (service providers) support it.

When should we hire a dedicated AppSec engineer?

When tier 1 applications outgrow what one person can review weekly, when a customer or regulator requires a named role, or when you begin selling software. Until then, an IT led program with an annual outside test is reasonable.

Most of the findings a team with no AppSec staff will face are in open source dependencies inside apps you own, and the hard part is getting from "we know" to "it is fixed" without a security engineer writing the change. 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 shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. If your agency will not let code leave its environment, this is the compromise from the Safeguard flow above: the scan runs where the code is.

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

The second 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. One in house developer can work a tier 2 backlog this way, with a person approving each change.

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

The third demo is a real Android session: you send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. For an IT lead who is rarely at a desk, the approval stays with you.

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

• CIS Control 16: Application Software Security
• CIS Control 2: Inventory and Control of Software Assets
• CIS Control 15: Service Provider Management
• CIS Controls Implementation Groups
• NIST SP 800-218, Secure Software Development Framework
• NIST Cybersecurity Framework
• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• FIRST Exploit Prediction Scoring System (EPSS)
• CISA Secure by Demand Guide
• CISA Secure by Design
• OWASP Top 10:2025
• OWASP Application Security Verification Standard
• CISA Software Bill of Materials
• NIST SP 800-218 (PDF)
• NIST Cybersecurity Framework 2.0, CSWP 29 (PDF)
• CIS Control 7: Continuous Vulnerability Management
• CIS Implementation Group 1
• CIS Implementation Group 2
• Safeguard docs: Application Security Testing (SAST and DAST)
• Safeguard docs: Local Runner
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: CI/CD Integration
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: AI Remediate
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Analytics and Dashboards
• Safeguard docs: Jira integration

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