Internal Audit of AppSec at a Bank: Answering the Request List

When internal audit reviews application security at a bank, the request list almost always covers seven areas: policy and standards, evidence that the secure development lifecycle ran, vulnerability management against your SLAs, the exception register, open source and third-party components, change management for releases, and the metrics you report upward. Auditors ask for complete populations (every release, every exception, every overdue finding in the period), pick samples, and trace each one to evidence that existed at the time. To avoid surprises, build those populations yourself before fieldwork, test a few samples the way the auditor will, and write down the gaps before they do.

This post is for the Head of Application Security at a US bank who has the request list and a week before fieldwork. It walks the list item by item, grounded in the IIA's Global Internal Audit Standards and Cybersecurity Topical Requirement, the Interagency Guidelines Establishing Information Security Standards, the FFIEC Development, Acquisition, and Maintenance booklet, and NIST SP 800-218 and SP 800-53. Most of it works with any tools. Safeguard comes in near the end, with its limits. This is general information, not audit or legal advice.

Key takeaways

• Under IIA Standard 13.4, auditors test against the criteria your board and senior management set, if they are adequate. A vague AppSec standard turns every sample into a debate.
• Under IIA Standard 14.1, evidence must be relevant, reliable and sufficient. Reports straight from a well controlled system beat edited spreadsheets.
• The IIA Cybersecurity Topical Requirement, effective 5 February 2026, sets a mandatory baseline for cybersecurity assurance work, including vulnerability monitoring, patching, software life cycle management and security in software development.
• 12 CFR Part 30 Appendix B expects regular, independent testing of key controls (III.C.3) and an annual board report that covers testing results and management's responses (III.F).
• Expect sampling from four populations: releases, exceptions, vulnerabilities past SLA and new open source components. Build each from a system of record and test five items yourself first.
• Draft findings get a management action plan with an owner, a date and a measurable end state, followed up under IIA Standard 15.2.
• Safeguard can supply part of the evidence: SBOM generation and analysis (GA), software composition analysis and vulnerability management with EPSS and CISA KEV (GA), reachability analysis (GA), policies, gates and guardrails with recorded outcomes and exception requests (GA), license compliance (GA), Portal audit trails (GA), bulk export (GA), the CLI (GA) and the desktop app (GA). Autonomous remediation (GA) ships switched off.
• Safeguard does not perform the audit, choose samples, write your policy or management responses, or produce evidence for code it never scanned.

The situation

The request list arrived Friday. Fieldwork starts Monday. Most lines sound reasonable on their own: "Provide the application security policy with approval evidence." "Provide all production releases for in-scope applications in the period." "Provide all vulnerability exceptions open at any point during the period."

The trouble is that the lines connect. The release listing is a population the auditor will sample. For each sampled release they will ask for the change ticket, the scan result at the time, the gate decision, and if a finding was accepted, the exception record. Each exception will be checked against the policy that says who may approve what, for how long. Every join is where a finding hides.

A bad week looks like this. The deployment tool and the security tool use different identifiers, so nobody can prove which scan covered which release. Three sampled exceptions expired in July and were never renewed. Two critical vulnerabilities passed their SLA and show as "accepted" with no approval behind them. None of that is unusual, and most of it is fixable, at least in part, if you look first.

The rules behind the request list

Internal audit works inside two sets of rules. The profession's standards decide how the engagement runs. Banking law and supervisory guidance describe a sound program, and give auditors criteria when your own policy is thin.

What do the IIA Global Internal Audit Standards expect of an audit engagement?

The IIA published the Global Internal Audit Standards in January 2024 as a mandatory part of its International Professional Practices Framework and expects all internal audit functions to conform. Domain V, "Performing Internal Audit Services," is where the request list comes from.

Two more shape the end of the engagement. Standard 11.5 requires the chief audit executive to discuss with senior management, and escalate to the board if unresolved, risk that management accepted beyond the bank's tolerance. A register full of long-expired risk acceptances invites exactly that. And under Standard 15.2, a missed action plan date can be treated as management accepting the risk by delay or inaction.

The IIA Cybersecurity Topical Requirement

The IIA issued its Cybersecurity Topical Requirement on 5 February 2025, effective 5 February 2026. It is mandatory for assurance engagements where cybersecurity is in scope, and auditors must document that each requirement was assessed for applicability.

Its control requirements land on AppSec directly. Auditors must assess whether there is a process to continuously monitor and report emerging threats and vulnerabilities and to prioritize improvements (item C), whether cybersecurity is part of the life cycle management of all IT assets including software and vendor services (item D), and whether processes cover configuration and patching and include cybersecurity in software development (item E). So much of your request list traces to a baseline the audit function is itself assessed against.

The Interagency Guidelines Establishing Information Security Standards

For national banks and federal savings associations, the OCC's version is 12 CFR Part 30, Appendix B; the FDIC and Federal Reserve have parallel versions. Three parts drive AppSec evidence:

• III.C.1.d asks the bank to consider procedures to ensure changes to customer information systems are consistent with the security program. For applications, that is change management with security checks built in.
• III.C.3 expects regular testing of key controls, with frequency set by the risk assessment, conducted or reviewed by independent third parties or staff independent of those who build or maintain the program. Internal audit is one way banks meet that.
• III.F expects a report to the board or a committee at least annually, covering material matters such as control decisions, results of testing and management's responses.

Section III.D covers service provider oversight; the post on how banks oversee service providers under the interagency guidelines covers that side.

What does the FFIEC Development, Acquisition, and Maintenance booklet expect?

The FFIEC revised this booklet in August 2024. The Federal Reserve issued it as SR 24-6 and the FDIC as FIL-60-2024, both on 29 August 2024; it replaced the April 2004 Development and Acquisition booklet. Per the FDIC, it describes what examiners review across governance of common risks, development planning and design, acquisition of IT systems and components, and maintenance and change control, and it does not impose new requirements on examined entities. Internal auditors often borrow its examination procedures as a work program, so read its acquisition and maintenance sections against your process. The FFIEC handbook site blocked our automated fetch, so we rely on the agencies' issuance letters for its scope and quote none of its sections here.

NIST SP 800-218 and SP 800-53

Neither binds a bank, but both are common sources of criteria when your own standards are silent. From the SSDF (SP 800-218 version 1.1, February 2022):

• PO.1.1: document security requirements for development and keep them current. Your policy.
• PO.3.3: configure tools to generate artifacts that support secure development, such as an audit trail.
• PO.4.1: define criteria for security checks and track them, with KPIs and KRIs. Your metrics.
• PS.3.2: keep provenance data for all components of each release, for example in an SBOM.
• PW.4.1 and PW.4.4: acquire well-secured third-party components and verify they meet your requirements throughout their life cycles.
• RV.2.2: plan risk responses for vulnerabilities, including a risk-based decision to remediate or accept.

From SP 800-53 Revision 5: SA-11 asks for evidence of testing results, a verifiable flaw remediation process and correction of flaws; SR-4 asks for documented, maintained provenance of components; CM-3 asks that configuration-controlled changes be reviewed, approved, documented and retained; RA-5 asks for vulnerability remediation in line with an assessment of risk.

The current SBOM baseline

If the list asks about SBOMs, cite the 2026 Minimum Elements for a Software Bill of Materials, published on 29 July 2026 by CISA with NSA, FBI and international partners. It updates the 2021 NTIA minimum elements and adds fields including SBOM Generation Context, SBOM Tool Name, Component Hash and Component License.

The request list, item by item

For each area: what is tested, good evidence, and the gaps that usually become findings. Your auditor's wording will differ. The shape rarely does.

1. Policy and standards

Requests. The AppSec policy and standards (secure coding, vulnerability management, open source, exceptions), approval evidence, last review date, ownership.

Tested. Whether criteria exist and are adequate (IIA 13.4) and are governed: approved, reviewed, owned.

Good evidence. A current, approved policy with version history, and standards with measurable requirements: remediation timeframes by severity, who can approve exceptions and for how long, which scans are required before release, which applications are in scope.

Findings.

• Review is overdue and nobody noticed.
• "Remediate critical vulnerabilities promptly" with no number, so the criterion is not measurable.
• The named exception approver role no longer exists.

2. Secure development lifecycle evidence

Requests. The SDLC with security activities marked. For sampled releases: code review, static analysis, dependency scanning, and any other testing your standard requires.

Tested. Whether required activities ran for each sampled release before it shipped (SSDF PW.7 and PW.8, SP 800-53 SA-11).

Good evidence. A scan record tied to the exact version that shipped, dated before deployment, with its result and gate decision; a peer review record; a pipeline where the security step is mandatory.

Findings.

• Scans ran nightly on main but not on the release build.
• The security stage can be skipped manually, and sampled releases did so with no reason recorded.
• The tool shows only today's findings, not what it showed on release day.

3. Vulnerability management and SLAs

Requests. SLAs by severity; all vulnerabilities identified in the period with discovery, due and closure dates; aging reports; how severity is assigned, including any use of EPSS or CISA KEV.

Tested. Whether findings are prioritized and closed on time, and overdue ones escalated or excepted (Topical Requirement items C and E, SSDF RV.2, RA-5).

Good evidence. A system export of all findings in the period with the query visible. A consistent severity and due date rule. Objective closure: a later scan showing the fixed version, not just a ticket marked Done.

Findings.

• The SLA clock starts at triage, not first detection, and the standard does not say which.
• Severity downgrades with no recorded reason.
• Overdue findings with no exception or escalation.

4. Exceptions and risk acceptances

Requests. Every exception open at any point in the period, with requester, approver, dates, expiry, justification and compensating controls; for samples, approval and evidence of review at expiry.

Tested. The right approver, a time limit, a real justification, and action at expiry (IIA 11.5, SSDF RV.2.2). The posts on how auditors sample vulnerability exceptions and preparing for an auditor walkthrough of your exception process go deeper.

Good evidence. One system, each exception linked to its finding and policy, with expiry, an authorized approver and a history.

Findings.

• Approvals lived in email or chat and were reconstructed later.
• Expired exceptions with the finding still open.
• Requester and approver are the same person.
• Findings marked "accepted" in the scanner that are not in the register.

5. Open source and third-party components

Requests. The component inventory for in-scope applications, the approval process for new components, vulnerability and license assessment for sampled releases, and your response to major new vulnerabilities in widely used components.

Tested. SSDF PW.4 and PS.3.2, SP 800-53 SR-4, the Topical Requirement's life cycle item, and the acquisition themes of the DA&M booklet.

Good evidence. An SBOM per release in SPDX or CycloneDX, with tool and date, plus vulnerability and license results and a policy decision. For a widely publicized vulnerability in the period, a record of which applications were affected, when you knew, and when each was fixed.

Findings.

• The inventory is a one-time export from last year.
• Transitive dependencies or container base images are missing.
• No record of the response to a major vulnerability, only memory of a busy week.

6. Change management for releases

Requests. All production releases for in-scope applications; for samples, the change ticket, approvals, test evidence, security gate result and deployment record; emergency changes.

Tested. Appendix B III.C.1.d, CM-3, and the DA&M booklet's change control focus: did required security checks happen before the change reached production?

Good evidence. A release population that joins to scan records by version or commit, a gate decision per release, and retrospective security review for emergency changes.

Findings.

• Releases and scans cannot be joined.
• Emergency changes skip the gate and never get the retrospective review.

7. Metrics and reporting

Requests. AppSec metrics reported upward in the period, with data and method.

Tested. SSDF PO.4.1, the Topical Requirement's governance items, Appendix B III.F. Auditors often re-perform a metric from raw data.

Good evidence. A written definition per metric (numerator, denominator, scope, source) and retained raw data that reproduces the number.

Findings.

• "Percent closed within SLA" quietly excludes excepted findings.
• Nobody can reproduce last quarter's board number.

Step by step: the week before fieldwork

This works with any tool set. The goal is to find what the auditor will find, then fix it or state it first.

1. Confirm scope in writing. Under IIA 13.1 the auditor communicates scope and timing. Ask for in-scope applications, the period, and whether vendor-built code is in scope.
2. Build a PBC tracker. One row per request line (template below). The post on what a PBC list is and how to answer it covers the mechanics.
3. Pull each population from a system of record. Releases, findings, exceptions, new components. Record the system, the query, the time and who ran it. Keep the raw export unedited.
4. Reconcile. Every release should join to a scan, every overdue finding to an exception or escalation, every exception to a finding and a policy. List what does not join.
5. Test five samples yourself. Some random, some from the riskiest applications, some near period end. Walk each from request to evidence.
6. Write down every gap. Policy, condition, root cause, action. This is the draft of your management response.
7. Fix forward, honestly. Renew expired exceptions with today's date or close them. Never backdate approvals or edit records.
8. Prepare walkthrough narratives. One page per area: who does what, in which system, leaving which record.
9. Name one owner per area so requests are answered within a day.

A PBC tracker template you can use today

How will auditors sample releases and exceptions, and how do you prepare a clean population?

Sample size and method come from the internal audit function's own methodology, which the IIA standards require the chief audit executive to establish. You do not control the method. You control the population, and a clean one is:

• Complete. Auditors test completeness by tracing items from another source (a deployment log, a ticket, a scanner finding) into your list. One missing release puts the whole population in doubt.
• Accurate. Dates, severities and approvers are right.
• Reproducible. A system report with visible parameters, or a saved query, meets Standard 14.1's reliability test far better than a hand-built spreadsheet.
• Joinable. It carries a key that links to evidence: version or commit for releases, finding and policy identifiers for exceptions.

For exceptions, include everything open at any point in the period. One created in February that expired in May is in the population.

A worked example, illustrative only, with invented round numbers: the in-scope applications shipped 400 releases, and your listing shows 380. The other 20 were emergency changes logged in a different queue. Found by you, you add them, explain why, and check whether they passed the gate. Found by the auditor, the population is incomplete and every conclusion drawn from it is weaker.

What evidence shows open source components were inventoried, assessed and patched?

For a sampled release, auditors want:

1. Inventoried. An SBOM for the shipped version, including transitive dependencies and container layers, with tool, format and date.
2. Assessed. Vulnerability results at release time and the policy decision that followed: passed, warned or blocked, and an exception if a known vulnerability shipped.
3. License reviewed. License identifiers per component and a decision against your standard.
4. Patched over time. For the period, evidence that new vulnerabilities in production components were caught by continuous monitoring and fixed or excepted within SLA. One high-profile vulnerability, traced from first detection to the last application fixed, shows this well.

The weak point is usually item two. Many tools show today's view, not release day's. If yours does, say so in the walkthrough and show how you keep point-in-time records (saved reports, pipeline logs, exports).

Which gaps usually become findings, and how do you get ahead of them?

Most recurring AppSec findings share a root cause: evidence that depends on someone remembering to create it.

Disclose and correct forward. A gap management found and started fixing usually lands differently from one the auditor found alone, though the auditor still decides whether it is a finding.

How do you respond to draft findings with a management action plan?

Under IIA 14.3 and 14.4 the auditor rates significance, works with management on root cause, and asks for action plans. Under 13.1, disagreement goes through an established method. Under 15.2, internal audit follows up and tracks status. A good plan has six parts:

1. Agree, partially agree or disagree. Disagree on facts with evidence; on significance in terms of likelihood and impact.
2. Root cause. Not "human error." Something fixable: nothing enforces exception expiry, the release key is not carried into the scanner.
3. Actions. Testable. "Release builds cannot deploy without a recorded gate decision" is testable. "Improve awareness" is not.
4. Owner. A named role.
5. Date. Realistic, since a missed date may be read as risk acceptance.
6. Completion evidence. What you will hand over at follow-up: a configuration, a report, records produced after the fix.

Keep actions inside your authority. If a fix depends on another team, get that owner's agreement first.

How Safeguard does this

Everything here comes from Safeguard's offering documentation and docs.safeguard.sh. Where the docs show no screen or command, we describe the outcome.

1. Connect the in-scope applications. Under Integrations, connect repositories (GitHub, GitLab, Bitbucket or a generic Git URL), container registries, or upload manifests. Software composition analysis (GA) builds the transitive inventory, including container layers, and SBOM generation and analysis (GA) produces SPDX and CycloneDX SBOMs. The docs describe daily continuous scanning plus optional triggers on push, on a schedule, and on release when tags are created. Turn on the release trigger: it ties an SBOM to each tagged version.

2. Tie scans to releases in CI. The Safeguard CLI (GA) runs as one pipeline step, and the docs say each push becomes a new project version named after the branch and commit (for example main-a1b2c3d). That name is the join key between your release listing and your scan records. Per the docs, create a secret key under Settings, then Developer, with scopes scans:trigger and scans:read, store it as SAFEGUARD_API_KEY, and add the step:

curl -fsSL https://cli.safeguard.sh/install | bash
safeguard ci scan --wait --fail-on critical

To fail on a policy gate instead of a severity, the docs show this form (we did not run either snippet for this post):

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

The docs note SAST findings are shown in Safeguard but are not part of the severity failure flag yet.

3. Write the standard as gates. Policies, gates and guardrails (GA) turn your standard into checks. Policies are built under Settings, then Policies, with a visual builder or YAML, on conditions such as severity, CVSS, EPSS, license, component age and abandoned packages. Each policy has one Action: Block (the gate fails), Warn (the gate passes with a warning naming the policy) or Notify (the gate passes and your configured channels are notified). Approval runs through exceptions, not through a gate action.

4. Keep a recorded outcome for every evaluation. With policy outcomes on, each evaluation records Passed, Failed, Warning, Not evaluated or Error, with a timestamp. Expanding a gate shows each policy's outcome, its effect, the matches and the gate's evaluation history. An Error never counts as a pass. For a sampled release, that history is the point-in-time record of what the gate decided. Safeguard turns policy outcomes on per workspace, so confirm yours is on well before the period you want covered.

5. Route exceptions through one workflow. Per the docs, an exception request names the policy and finding, a business justification and an expiry date, and goes for approval; approvers are notified, decide, and an audit trail is recorded. On the Vulnerabilities page, Accept Risk takes an expiry and justification and goes for approval; Mark False Positive takes a justification. That gives you one exception population, each item linked to its finding and policy.

6. Show prioritization and SLA data. Vulnerability management (GA) draws on NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins, and shows CVSS, EPSS, exploitable status, fixed version and reachability per finding. Reachability analysis (GA) shows whether the vulnerable code path is called. Filters by severity, EPSS range, exploitable status, fix availability and date range build the aging views auditors ask for.

7. Answer license questions. License compliance (GA) shows each component's SPDX identifier, category and compliance status. License policies (allowlist, blocklist, review list) can fail gates, and Export, then License Report, produces summary, detailed, attribution and compliance reports.

8. Export populations, not screenshots. Bulk export (GA) covers tables in CSV, Excel, PDF, JSON and other formats, with filtering and column selection on every table. Export the full population with the filter visible and keep the file unedited.

9. Use Portal audit trails for SBOM handling. If you publish or share SBOMs through Portal, the SBOM publish and share product (GA), its audit trails log SBOM creation, changes, views, downloads, sharing and permission changes, with timestamp, actor, action, resource and result. View them under Settings, then Audit Logs, filter, and export as CSV, JSON or PDF. The docs list default retention by log type; check it against your retention schedule. That page carries a banner that its REST endpoints are not available yet, so use the in-app export.

10. Close findings with a person approving. Autonomous remediation (GA) can open tested, policy gated pull requests to fixed versions, one repository at a time or in bulk. It ships switched off, every category set to Manual. Merged pull requests plus a later scan showing the fixed version make clean completion evidence.

11. Answer questions during walkthroughs. The CLI's interactive terminal and the desktop app (GA) let an engineer run a scan on the spot; since CLI v11.10.0 the CLI asks before any command that changes something. The MCP server (GA) has read-only tools for gate outcomes and evaluation history where your access settings allow.

Request list mapped to Safeguard evidence

What stays with the bank

• Policy ownership. The board and senior management set the criteria. A tool can enforce a rule; it cannot decide or approve it.
• The independence of audit. Internal audit picks scope, samples and conclusions and reports under its charter. Your job is to make evidence available, not to shape what is tested.
• Management responses. The action plan, owner and date are management's commitments.
• Risk acceptance. Who may accept which risk, and for how long, is a governance decision, escalated under IIA 11.5 when it exceeds tolerance.
• Board reporting. The Appendix B III.F report is management's report.

What Safeguard does not do

• It does not perform or replace the audit. It does not select samples, test controls, form conclusions or write findings. It is one source of evidence the auditor may choose to rely on.
• Evidence covers only what it scans and gates. Unconnected applications, releases that bypass the CI step, or gates not linked to the right policies leave gaps it cannot see.
• Policy outcomes are enabled per workspace. If they were turned on partway through the audit period, say so in the walkthrough.
• It does not write your policy, approve exceptions or draft management responses. People make those decisions; the workflow records them.
• It does not cover every testing activity. Peer review, threat modelling, manual penetration testing and business logic review stay in your other processes, and the CI severity flag does not cover SAST findings yet.
• Some documented APIs are not available yet. The audit trails and suppliers and licenses pages say their REST endpoints return 404 today.
• It does not fix code you do not build. Vendor-hosted applications, appliances and operating system runtimes are outside its remediation scope.
• It is not audit advice. How your audit function applies the IIA standards is for your chief audit executive, compliance team and counsel.

Common mistakes

• Answering the request, not the test. "Provide releases" means "prove every release went through your controls." Send the listing with its join to scan records.
• Filtering the population. Sending only closed exceptions looks like hiding something. Send everything in scope.
• Editing evidence. Re-export unedited and explain errors separately.
• Backdating approvals. An exception approved today carries today's date.
• Describing the process you want. If you describe a mandatory gate that is optional, every sample fails.
• Committing to dates you cannot meet. A missed date becomes its own conversation under IIA 15.2.
• Forgetting other teams. Change, release and vendor evidence come from elsewhere. Line them up before Monday.

FAQ

What does internal audit ask for in an application security audit at a bank?

Usually the AppSec policy and standards, SDLC evidence for sampled releases, a vulnerability population with SLA data, the exception register, open source inventory and assessment, release change records, and the metrics reported upward, each tested by sampling.

How many releases or exceptions will the auditor sample?

That depends on the audit function's methodology, the population size and risk. The IIA standards require the chief audit executive to set methodologies; they do not give you a number. Be ready to support any item.

Does the IIA Cybersecurity Topical Requirement apply to an AppSec audit?

If your audit function conforms to the IIA standards and cybersecurity is in scope, yes. It took effect on 5 February 2026, and excluded requirements need a documented rationale.

Is the FFIEC DA&M booklet a new requirement for banks?

The FDIC states that the August 2024 booklet does not impose new requirements. It describes what examiners review, and auditors often use it as a reference.

What is the difference between an exception and a risk acceptance?

Banks use the terms differently. Commonly, an exception is a time-limited departure from policy for a specific finding, and a risk acceptance is an authorized person's decision to carry the risk. Your standard should define both, with approvers and maximum durations.

What counts as good evidence for open source components?

An SBOM tied to the shipped version, vulnerability and license results at release time, a policy decision, and records that new vulnerabilities in production components were fixed or excepted within SLA.

What if we disagree with a draft finding?

Say so with evidence. IIA 13.1 requires an established method for both sides to state their positions, and the auditor is not obliged to change a result without a valid reason.

How long should we keep AppSec evidence?

As long as your bank's record retention schedule requires, and at least through the audit period and follow-up. If a tool keeps less, export and store the evidence.

Clean evidence keeps the audit short, but the finding that hurts most is a known vulnerability left open past SLA because no fix was easy to ship. The section below covers how Safeguard narrows that gap for the open source components you build and ship.

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: install, open the interactive terminal with safeguard, and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. In an audit, /scan is how an engineer produces a fresh SBOM and findings during a walkthrough, and the approved, tested fix is the kind of completion evidence an action plan needs.

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

The second demo is a session in the Safeguard desktop app. The CLI session appears in the conversation list, you ask for work on your computer, choose the folder, then Approve or Deny each command and file edit, and the session ends with a dependency upgrade done and tests passing. For an AppSec lead closing audit findings, that per-step approval shows a person reviewed each change before it reached a release.

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

To try it on your own applications before fieldwork, download the app and CLI at https://safeguard.sh/download and read the setup guides at https://docs.safeguard.sh/docs .

Quick check

Sources

• The IIA, Global Internal Audit Standards (overview)
• The IIA, Global Internal Audit Standards, full text
• The IIA, Cybersecurity Topical Requirement (overview)
• The IIA, Cybersecurity Topical Requirement, full text
• eCFR, 12 CFR Part 30, Appendix B
• Federal Reserve, SR 24-6
• FDIC, FIL-60-2024
• OCC, Bulletin 2024-26
• NIST SP 800-218, SSDF version 1.1
• NIST SP 800-53 Rev. 5 catalog, official NIST OSCAL content
• CISA, 2026 Minimum Elements for an SBOM
• 2026 Minimum Elements for an SBOM, PDF
• Safeguard docs, Policies and Gates
• Safeguard docs, Policy outcomes and actions
• Safeguard docs, Generate SBOM
• Safeguard docs, CI/CD Integration
• Safeguard docs, Vulnerabilities
• Safeguard docs, Suppliers and Licenses
• Safeguard docs, Portal Audit Trails

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