Build a DoD Software Fast Track (SWFT) Package From Your Pipeline

DoD's Software Fast Track (SWFT) asks software vendors for a body of evidence instead of a one-time authorization package: a component-level SBOM, vulnerability results, proof of secure development practice against NIST SP 800-218, and an independent third-party assessment that DoD then uses to make its own risk decision. As of 25 October 2026 we could not find a final, public SWFT framework on any DoD or other .gov source, so treat the detailed requirements as unsettled. The practical move is the same either way: generate every artifact from your pipeline so it refreshes on each release, instead of assembling it by hand for each program office.

This post is for the platform, release or DevSecOps lead at a company selling software to the Department of Defense directly or through a prime. It covers what DoD has actually published, how SWFT sits next to RMF and continuous ATO, which artifacts to produce, and how Safeguard handles the pipeline side today, including what it cannot do.

Key takeaways

• SWFT is real, but its final rules are not public as far as we can confirm. The DoD CIO memo "Accelerating Secure Software" (24 April 2025) directed the initiative and asked for a framework and implementation plan within 90 days. Three requests for information followed on 2 May 2025. We found no published final framework on dodcio.defense.gov, sam.gov or other .gov sources reachable on 25 October 2026.
• The shape is clear even without the final text. The RFIs describe a voluntary route where a company supplies a third-party produced SBOM plus an independent third-party assessment, and they ask about SSDF attestation, component-level SBOMs and automated sharing of risk artifacts.
• SWFT does not replace your customer's RMF obligations. DoDI 8510.01 still governs authorization of DoD systems, and continuous ATO under the February 2022 memo is earned by the system owner and authorizing official, not by a vendor.
• Build once per release, not once per program. An SBOM, a vulnerability report with exploitation context, signed attestations and a gate record should come out of every release build automatically.
• Federal SBOM expectations moved in 2026. OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16, and CISA's 2026 Minimum Elements for an SBOM (29 July 2026) replaced the NTIA 2021 baseline with new fields such as SBOM Author Signature, Component Hash and SBOM Generation Context.
• Safeguard capabilities in this post and their maturity: SBOM generation and analysis (SPDX, CycloneDX), GA. SCA and vulnerability management with EPSS and CISA KEV, GA. Reachability analysis, GA. Attestation and signing, GA. Policies, gates and guardrails, GA. Portal, the SBOM publish and share product, with its EO 14028 compliance checks, GA. Bulk export, GA. CLI and local runner, GA. On-prem and air-gapped deployment and Zero AI mode, GA. CSAF and VEX upload, GA. Autonomous remediation, GA, ships switched off.
• What Safeguard is not: an independent assessor, an authorizing official, or a holder of any DoD authorization. Safeguard's architecture is designed for FedRAMP High; that is a design target, not an authorization.

What is SWFT, what did the DoD CIO RFIs ask for, and what is its status now?

The April 2025 memo

On 24 April 2025, Katherine Arrington, then performing the duties of the DoD Chief Information Officer, signed a one-page memorandum titled "Accelerating Secure Software." It was cleared for open publication on 2 May 2025. The memo makes two observations that frame everything after it. First, lengthy and outdated cybersecurity authorization processes get in the way of continuous delivery. Second, heavy use of open source software means the Department lacks visibility into where code comes from and how secure it is.

To address both, the memo directs a Software Fast Track (SWFT) Initiative. It says the initiative will define four things, clearly and specifically:

1. Cybersecurity and supply chain risk management (SCRM) requirements.
2. Rigorous software security verification processes.
3. Secure information sharing mechanisms.
4. Federal Government-led risk determinations, so that cybersecurity authorizations for rapid software adoption move faster.

The DoD CIO, in coordination with the Under Secretaries of Defense for Acquisition and Sustainment, Intelligence and Security, and Research and Engineering, was told to develop and submit a SWFT Framework and Implementation Plan within 90 days. The memo itself sets no vendor requirements. It sets a direction and a deadline.

The three RFIs

On 2 May 2025, DoD posted three requests for information to SAM.gov, each with responses due on 20 May 2025:

The Tools and External Assessment RFIs share a background paragraph that is the clearest public statement of what a vendor might be asked for. In our own words: to speed up the Authorization to Operate process for software DoD adopts, the CIO's office had developed a voluntary procedure in which a company provides an SBOM produced by a third party, together with an independent third-party assessment of its software, so the Department can evaluate and adopt that software faster.

The Tools RFI then asks six questions. In short: which standards you follow; what gets in the way of implementing NIST SP 800-218 and producing an attestation, since SWFT may assess it; whether you provide an SBOM with component (artifact) level detail and with which tools; which risk artifacts you produce and whether automated tools produce them; whether those artifacts could be shared for DoD-led risk assessment; and how you could support secure, automated information sharing.

The External Assessment RFI asks the mirror-image questions of assessors: what qualifications and independence an external assessor needs, and how an assessment could evaluate SWFT artifacts, the supplier's SBOM included, and feed automated sharing.

Read together, the RFIs point at four artifact families: an SBOM, evidence of SSDF practice (likely in attestation form), automated risk artifacts such as vulnerability results, and a third-party assessment report. That is the working definition of a "SWFT package" in this post.

What DoD said publicly in mid 2025

On 16 July 2025, Cynthia Carpenter, Director of DIB Operations in the DoD CIO's cybersecurity directorate, presented SWFT at a NIST event (slides on csrc.nist.gov). They show DoD publishing SWFT requirements, suppliers providing a SWFT body of evidence, a third-party assessment organization (3PAO) assessing it, and DoD approving, with automated continuous monitoring alongside.

AFCEA's Signal magazine reported on 8 July 2025 that the initiative was officially implemented on 1 June 2025, that the framework and implementation plan were due at the end of July, and that the team was still deciding which artifacts the risk determination would require. Response counts in press coverage disagree (420 in Signal, above 500 elsewhere), so we rely on neither.

Status as of 25 October 2026: what we could and could not confirm

We confirmed the April 2025 memo, the three RFIs and the July 2025 NIST presentation. We did not find a final SWFT framework, implementation plan, required artifact list or named assessment scheme on any official .mil or .gov source. The dodcio.defense.gov site refused automated requests, so we read DoD documents through public archive copies; something posted there since may exist that we could not see.

Some vendor blogs describe 2026 SWFT "phases" and compliance dates. We could not trace them to a DoD source, and at least one mixes in terms from the separate CMMC program. If your contracting officer or program office hands you SWFT instructions, those are the requirement. Until then, build for the four artifact families above and keep the package easy to reshape.

For background on the wider DoD SBOM picture, see our earlier post on SBOM requirements under DoD software supply chain risk management programs.

How does SWFT relate to RMF under DoDI 8510.01 and to continuous ATO?

RMF still governs DoD systems

DoD Instruction 8510.01, "Risk Management Framework for DoD Systems," effective 19 July 2022, establishes the RMF for DoD systems and assigns who does what. It includes guidance on reciprocity of authorization decisions with other federal agencies, and its task table includes continuous monitoring and, at Task M-6, ongoing authorization in which authorizing officials use the results of continuous monitoring.

Nothing we found says SWFT replaces DoDI 8510.01. The memo's own wording is about expediting authorizations, and the RFIs talk about equipping authorizing officials with product-specific risk information. The most defensible reading is that SWFT aims to give the authorizing official better, reusable evidence about a software product so the system-level RMF work goes faster. Your customer's system still needs an authorization decision; the system owner still owns its security plan and continuous monitoring strategy.

Continuous ATO is a system state, not a vendor badge

The DoD memo "Continuous Authorization To Operate (cATO)," issued in February 2022 by the DoD Senior Information Security Officer, names three competencies an authorizing official must show before a system moves to cATO: continuous monitoring of RMF controls inside the boundary, active cyber defense in near real time, and use of an approved DevSecOps reference design. DoD CISO approved cATOs do not expire while that posture holds, and can be revoked. The memo's supply chain section says an approved software platform and development pipeline are critical, in part to support creating an SBOM.

That is the bridge to SWFT. A program under cATO wants supplier component and risk data it can feed into continuous monitoring. A vendor that supplies a fresh SBOM, vulnerability report and signed provenance on every release makes that cheaper; a yearly PDF makes it harder. We cover cATO in more depth in ATO and continuous ATO for government software, and the pipeline architecture side in DoD software factory reference design and secure software factory architecture.

Which artifacts does a vendor supply, and in which formats?

Until DoD publishes a final list, build for the artifact families the RFIs name, in formats that standards bodies define and that tools on the receiving side already read.

The SBOM

The Tools RFI asks for an SBOM "that includes software component (artifact) level of details." Produce it in SPDX or CycloneDX for every release, named by product and version. The RFIs also mention a third-party produced SBOM; whether DoD will accept a vendor SBOM that an assessor validates is not settled in anything we found, so keep generation documented and repeatable so an assessor can rerun it.

Vulnerability results with exploitation context

A list of CVE IDs is not a risk artifact. For each finding, state the component and version, severity, whether it is in CISA's Known Exploited Vulnerabilities catalog (which CISA calls the authoritative source of vulnerabilities exploited in the wild), its EPSS score (FIRST's estimate of the probability of exploitation in the next 30 days), whether a fix exists, and your response. For findings that do not affect your product, a VEX statement says so in machine-readable form.

Secure development evidence

The Tools RFI says SWFT may assess how you implement NIST SP 800-218, the Secure Software Development Framework (SSDF), and asks about producing an attestation. The tasks most directly served by pipeline artifacts are:

• PS.3.2: collect, safeguard, maintain and share provenance data for all components of each software release, for example in an SBOM.
• PS.2.1: make software integrity verification information available to software acquirers.
• PW.4.4: verify that acquired commercial, open source and other third-party components comply with your requirements throughout their life cycles.
• RV.1.1: gather information from acquirers, users and public sources on potential vulnerabilities in the software and its third-party components, and investigate credible reports.
• PO.3.2: follow recommended security practices to deploy, operate and maintain tools and toolchains.

An SSDF attestation is a signed statement by your company. Pipeline artifacts are the evidence behind it. For a fuller treatment, see the sibling post how to prove secure software development to a federal contracting officer.

Build provenance and signatures

SLSA v1.0 defines a build track with levels L0 through L3: L1 means provenance exists, L2 means signed provenance from a hosted build platform, and L3 means a hardened build platform. The earlier SLSA 1 to 4 scale belongs to a previous version of the specification, so there is no Build L4 in the current spec. Provenance in in-toto format, bound to the artifact's digest and signed, lets a reviewer check where a release came from without trusting your cover letter. The sibling post show SLSA build provenance to a federal agency customer goes deep on this.

The third-party assessment

This is the one artifact you cannot generate. What you can do is make the assessor's job short: every artifact dated, versioned, signed where possible and traceable to a specific build.

How do OMB M-26-05 and the CISA 2026 SBOM minimum elements affect what a defense vendor already produces?

OMB M-26-05

On 23 January 2026, OMB Director Russell Vought issued M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security." It rescinds M-22-18 and its companion M-23-16, the memos that had required agencies to collect secure software development self-attestations from producers. M-26-05 keeps two obligations for agencies: maintain a complete inventory of software and hardware, and develop assurance policies that match their risk determinations and mission needs.

It also leaves the old tools on the table. Agencies may still use the Secure Software Development Attestation Form. They may adopt contract terms requiring a producer to provide a current SBOM upon request, and for a cloud platform the memo says such a term should cover an SBOM of the runtime production environment. It points agencies to NIST SP 800-218, to CISA's SBOM minimum elements (then in draft) and to CISA's hardware bill of materials framework.

For a defense vendor, the practical effect is that the blanket civilian attestation requirement is gone, while the artifacts behind it are now requested contract by contract. M-26-05 is addressed to executive departments and agencies; how a given DoD program applies it alongside its own policies and the SWFT direction is for that program to say. Our post on OMB M-26-05 and what changed for software suppliers covers the civilian side in detail.

The CISA 2026 Minimum Elements for an SBOM

On 29 July 2026, CISA, NSA, FBI and international partners released "2026 Minimum Elements for a Software Bill of Materials (SBOM)." It builds on and replaces the NTIA 2021 minimum elements as the baseline. The document lists ten new elements: SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Generation Context, SBOM Tool Name, SBOM Tool Version, SBOM Version, Component Hash Value, Component Hash Algorithm and Component License. It makes major updates to SBOM Author, Component Producer, Component Identifiers and Component Version, and minor updates to SBOM Timestamp, Component Name and Component Dependency Relationship. On the practices side, it updates Coverage, Machine-Processable Data, Explicitly Identifying Unknown Information, Accommodation of Updates to SBOM Data, Distribution and Delivery and Frequency, and it drops the separate Access Controls element.

Three changes matter most for a pipeline:

• SBOM Author Signature. The SBOM should carry a digital signature attributable to its author, using an approved signature algorithm, so a recipient can tell it was not modified after signing.
• SBOM Generation Context. The SBOM should say where in the life cycle it was generated, such as "before build," "build" or "after build." A source scan and a scan of the shipped container are different documents and should say so.
• Frequency. Each software version or update should have its own SBOM, and a new build or release should produce a new SBOM. A corrected SBOM gets a new version.

SBOMs built for the NTIA 2021 fields often lack component hashes, licenses, tool name and generation context. Check yours against the 2026 list before it goes to a program office.

How do you generate and sign the artifacts on every release without manual work?

The design principle is simple: the release pipeline is the only place release artifacts are made. Anything assembled later by hand will drift from what you shipped.

A release pipeline that produces the package

1. Pin inputs. Commit lockfiles, pin base images by digest, and pin CI actions or plugins to exact versions. An SBOM is only as precise as the dependency resolution behind it.
2. Build on a hosted or dedicated build platform. Builds on a developer workstation cannot reach SLSA Build L2 or L3.
3. Generate SBOMs at two points. One from source and lockfiles before build, one from the built artifact or container image after build. Record the generation context on each.
4. Scan the SBOMs, not just the source. Match components against vulnerability databases, enrich with KEV and EPSS, and record fix availability.
5. Evaluate policy and record the result. A gate that blocks, warns or requires approval turns your vulnerability policy into evidence. Keep the decision and any exception with its expiry and justification.
6. Attest and sign. Produce provenance and SBOM attestations bound to the artifact digest and sign them. Sign the SBOM files themselves too, to meet the new SBOM Author Signature element.
7. Publish to a controlled store. Put the SBOMs, reports, attestations and gate record next to the release in an immutable, access-controlled location, keyed by product and version.
8. Rescan on a schedule. New CVEs land after release. A daily rescan of the stored SBOMs keeps the vulnerability report current without a rebuild.
9. Export on request. When a program office or assessor asks, export the package for a version in the format they want, not a fresh hand-made bundle.

What "without manual work" really means

Automation removes copy, paste and reformat steps, not judgment. Someone still signs the VEX statement and approves a gate exception. The goal is that human work happens once, is recorded with a name and a date, and carries forward to every later artifact.

Signing keys belong to you

The key that represents your company to DoD should be under your control, in a hardware security module or key management service, with rotation and a documented ceremony. A signature made with a tool vendor's key says something about the tool, not about you.

How do you handle the network constraints of classified or disconnected environments?

Defense software often runs where nothing reaches the internet: classified enclaves, tactical edge systems, or production networks with no outbound traffic. Three problems follow.

Vulnerability data goes stale. A scanner inside the enclave knows only the CVEs in the database it was given. You need signed, dated feed transfers on a known cadence, and every report should state its feed date.

Artifacts must cross a boundary. Reports come out and feeds go in through a cross-domain solution, a data diode or approved removable media. Small, signed, self-describing files cross more easily than database dumps.

Tooling must not phone home. Scanners, signing tools and assistants used inside must work with no outbound connection, and any AI component must run locally or be off.

The usual pattern is to generate the package on the unclassified side, where the build happens, and carry only verified artifacts and signed feed updates across. Either way, record which feed snapshot and tool versions produced each artifact.

How Safeguard does this job, step by step

Safeguard covers the pipeline side of a SWFT package: producing SBOMs, scanning them with exploitation context, gating releases, attesting, checking SBOM completeness, publishing and exporting, and doing all of that on a laptop, in CI, or inside an air-gapped perimeter. It does not produce the assessment, the attestation letter's legal signature, or any authorization.

The steps below use only flows and commands from Safeguard's docs. Where the docs show no command, we describe the outcome instead of inventing one.

Step 1. Install the CLI and sign in (CLI and local runner, GA)

The Safeguard CLI is a single static binary for macOS, Linux and Windows. The docs show this installer for macOS and Linux:

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

Then open the interactive terminal and sign in:

safeguard

Type /login, approve the session in your browser, and the runner built into the CLI starts. Sign-in is an OAuth 2.0 device-code flow; on a machine with no browser, safeguard login --no-browser prints a URL and code to enter elsewhere. The docs say the runner sends a heartbeat and polls the platform over outbound HTTPS that it opens itself, nothing connects inbound to it, and it uploads only the SBOM and findings, never source code. On networks that forbid held connections, safeguard runner start accepts --poll-wait 0 to poll at a fixed interval.

Step 2. Connect the repositories and images that make up the product (SBOM generation and analysis, GA)

In the web app, open Integrations from the sidebar. The docs list source code connections (GitHub, GitLab, Bitbucket and generic Git), container registries (Amazon ECR, Docker Hub, GCP and any OCI-compatible registry) and file uploads, including CSAF and VEX documents and package manifests. For each repository you choose the branch or tag, the project name and the version.

Then set scan triggers. Besides daily continuous scanning, the docs list On Push, Scheduled and On Release, which scans when a new tag is created. On Release ties a fresh SBOM and vulnerability result to every tagged version.

SBOMs are produced in SPDX and CycloneDX. The generation options include whether to include development dependencies and whether to run a deeper AI-assisted analysis; for a deployment that must run with no model at all, Safeguard's Zero AI mode (GA) runs the platform deterministically.

Step 3. Scan every release artifact in CI

For pipelines, the CLI scans exactly one target per run and writes JSON results under ./output by default. The docs show these forms:

# A local directory (your own or proprietary code)
safeguard scan --dir .

# A container image
safeguard scan --image nginx:latest

# A private registry
safeguard scan --image myregistry.azurecr.io/myapp:v1 \
  --registry-username "$REGISTRY_USER" \
  --registry-password "$REGISTRY_PASSWORD"

# An SBOM you already have (SPDX or CycloneDX, detected automatically)
safeguard scan --sbom sbom.json

Run the directory scan on source (your "before build" SBOM) and the image scan on the built container (your "after build" SBOM). Results include vuln.json, license.json and collection.json in a folder per scan.

Two details matter for pipeline design. safeguard scan does not fail on findings: it exits 0 when the scan ran, 1 when the command failed, and 2 when results were written but the vulnerability scan did not run, so a script never mistakes that for a clean pass. There is no severity threshold flag; gating happens in the platform (Step 5). On a fresh CI container, the docs say to put the underlying scanner tools on the PATH or point TOOLS_DIR at them.

Step 4. Validate the SBOM documents before they leave

The CLI can check SBOM and VEX documents against their specifications:

safeguard validate sbom.json --strict -o report.json

The docs say it checks CycloneDX (JSON and XML), SPDX (JSON, YAML, tag-value and RDF) and VEX (CSAF and OpenVEX), with --strict treating warnings as errors. This is a format check. It tells you the file is well formed, not that every CISA 2026 minimum element is populated. Step 7 covers completeness.

Step 5. Prioritize with KEV, EPSS and reachability, then gate the release (SCA and vulnerability management, GA; reachability analysis, GA; policies, gates and guardrails, GA)

In ESSCM, the Vulnerabilities tab groups findings as Critical, High, Medium, Low and Exploitable, the last meaning known exploitation in the wild. Each finding shows the CVE, CVSS, EPSS, whether it is exploited, the affected component and version, the fixed version, references and reachability. The docs list NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins as data sources.

Reachability analysis asks whether your code actually calls the vulnerable path. Safeguard's docs say reachability filtering removes 60 to 80% of findings from the urgent queue; treat that as Safeguard's stated figure, not a guaranteed result for your code. The docs list language support individually: JVM languages, Python, JavaScript and TypeScript, Go, Rust, C and C++, C#, Ruby, PHP, Swift and Objective-C.

For findings that do not apply, Mark False Positive and Accept Risk (with expiry and justification) go through approval where policy requires, and become part of the evidence.

Now gate. In Settings, Policies, choose Create Policy and define conditions with the visual builder or YAML. The docs list conditions on vulnerability severity, CVSS score, EPSS score, license, component age, maintenance and SLSA level, and templates such as No Critical Vulnerabilities, License Compliance, EO 14028 Compliance and SLSA Level 2. Each policy's action is Block (the gate fails), Warn or Notify. Exceptions are requested with a justification and an expiry, routed to approvers and recorded in an audit trail.

The docs say gates are evaluated by the platform on the scans it runs for connected repositories, and that with policy outcomes switched on for the workspace, this command fails a CI job when the gate fails:

safeguard ci scan --wait --fail-on-gate <gate>

The sibling post prove every production release passed a security gate covers the gate record in more detail.

When a fix exists, autonomous remediation (GA) can open a tested pull request that moves the dependency to a safe version. It ships switched off, with every category set to Manual, so your team chooses what runs automatically.

Step 6. Attest and sign the build (attestation and signing, GA)

The attestation docs describe five in-toto v1 attestation types: SLSA Provenance v1, CycloneDX SBOM, SPDX SBOM, a vulnerability scan snapshot at build time, and a Safeguard Review. Produce SLSA provenance in CI with your build platform's own attestation tooling, for example GitHub's artifact attestations or the SLSA GitHub generator. To check attestations that Safeguard signs, verify them against Safeguard's published public key as described at https://docs.safeguard.sh/docs/attestation-signing.

Read the signing section carefully, because it shapes what you can tell DoD. The docs say Safeguard signs attestations with its own ECDSA P-256 key held in a cloud key management service, and that recipients verify them with cosign against Safeguard's published public key. That gives an assessor a verifiable, tamper-evident record. It is a signature by Safeguard's key, though, not by your company's. If DoD asks for an SBOM signed by the SBOM author, plan to add your own signature with your own key alongside it.

The docs also say there is no CLI command for signing container images or packages yet, no CLI command for verifying attestations yet, and no public attestation API yet; attestation records appear on the Attestation tab in the app. Under the current SLSA v1.0 build track, Build L3 is the highest level, so target L2 or L3 and describe it in v1.0 terms; treat any L4 you meet as the older scale.

Step 7. Check SBOM completeness against the federal baseline (Portal, the SBOM publish and share product, GA)

ESSCM's EO 14028 Compliance Checks page describes a per-project Compliance tab with a score built from data completeness, format compliance, component coverage and SBOM freshness. To produce a report, open the project and choose Export, then EO 14028 Compliance Report, in PDF, HTML or JSON; it includes per-component completeness and a gap analysis. The docs say there is no CLI command for this, so use the app.

In Portal, the publish and share product, each SBOM also has a Compliance tab with automated verification of minimum fields, unique component identifiers, supplier data, versions, dependency relationships and hash values, plus a gap analysis. Portal reports include an EO 14028 Compliance Report, a minimum elements report, a Gap Analysis Report and a Full Audit Package, exported as PDF or Excel.

One honest caveat: on 25 October 2026 both docs pages still describe the check against the NTIA 2021 minimum elements, not CISA's 2026 list. The Portal check does include hash values, but neither page mentions SBOM Author Signature, SBOM Generation Context, SBOM Tool Name or Component License as checked fields. Use the Safeguard reports for the fields they cover, and check the 2026-only fields yourself until the docs say otherwise.

Step 8. Publish, share and export the package (Portal, GA; bulk export, GA)

In Portal, publishing moves an SBOM from ESSCM into Portal as an immutable copy, and sharing sends it onward as-is through direct links, a branded portal or NDA-gated, tracked access. The published copy records exactly what you gave the program office for a version, and the audit trail shows who opened it.

When an assessor wants data in a particular shape, Safeguard's tables support bulk export in CSV, Excel, PDF, HTML, JSON, XML, Markdown, TSV, NDJSON, Parquet and SQL. CSAF and VEX documents (GA) can be uploaded so "not affected" statements sit with the vulnerability data they qualify.

Step 9. Run it where the network cannot reach out (on-prem and air-gapped deployment, GA)

For disconnected environments, the docs describe a full air-gapped deployment in which the web app, scanners, CLI, runner and the AI models (or Zero AI mode, with no model at all) run inside your perimeter and no component inside calls outbound. A DMZ-positioned receiver verifies signed snapshot bundles and pushes deltas to the control plane. The docs say bundles carry vulnerability feed deltas from NVD, GitHub Advisory, OSV, CISA KEV and daily EPSS, plus policy template updates and platform binaries, and can arrive by one-way diode, signed removable media, a scheduled DMZ sync or a pull replica, on a cadence from hourly to quarterly.

For a single isolated build machine, safeguard update --import loads a vulnerability database downloaded elsewhere. Record the snapshot date in each report.

These are architecture choices. Safeguard's architecture is designed for FedRAMP High, which is a design target, not an authorization, and running Safeguard inside an enclave gives nobody a DoD approval.

Requirement vs what Safeguard does vs what you still own

What Safeguard does not do

• It does not perform the third-party assessment. The SWFT RFIs describe an independent assessment. Safeguard is a tool you use; an assessor must be independent of you and of your tools' vendor.
• It does not hold or confer any DoD authorization. Safeguard has no ATO, provisional authorization or SWFT approval, and using it does not give your product one. Its architecture is designed for FedRAMP High, a design target, not an authorization.
• It does not make the program office's risk decision. DoD's memo reserves risk determinations for the Federal Government. Safeguard's scores and compliance percentages are inputs, not decisions.
• It does not sign as your company. Attestations are signed with Safeguard's key. An SBOM Author Signature from your company, and your SSDF attestation letter, need your own key and your own signatory.
• Its SBOM completeness checks trail the 2026 baseline. As of this writing the docs describe checks against the NTIA 2021 minimum elements; you must verify CISA 2026 fields such as SBOM Author Signature, SBOM Generation Context, SBOM Tool Name and Component License yourself.
• There is no public attestation API. The attestation docs say so. Use the app, the CLI and CI steps.
• It cannot cover practices outside the pipeline. Personnel security, physical security, foreign ownership questions, financial health and other company-level risk factors that the SWFT effort has discussed are outside what a software supply chain tool can evidence.
• It cannot predict final SWFT requirements. If DoD publishes a format or field list Safeguard does not produce, you will need to fill the gap yourself until the product catches up.

Common mistakes

Treating vendor blogs as the SWFT rulebook. Several published SWFT timelines cannot be traced to DoD documents.

One SBOM per year, or per contract. CISA's Frequency element expects a new SBOM for every version and every update. A stale SBOM is worse than none, because it looks authoritative.

Mixing up SBOM contexts. Source and container SBOMs list different things. Label each with its generation context.

Sending raw scanner output. A CVE dump without KEV, EPSS, fix versions or reachability buries the findings that matter.

Letting a tool's signature stand in for yours. A signature from a vendor's key shows integrity of the record. It does not show that your company stands behind the content.

Claiming SLSA Level 4. The current SLSA spec ends at Build L3. Quoting L4 signals that you are working from an old version.

Forgetting the feed date. Offline, a report is only as current as its database snapshot. Date every report.

Calling a self-check a certification. A 100% completeness score on your own SBOM is a quality metric, not an approval.

FAQ

What is the DoD Software Fast Track (SWFT) initiative?

A DoD CIO initiative, directed by the 24 April 2025 memo "Accelerating Secure Software," to define security and supply chain requirements, verification, information sharing and government-led risk determinations so software is authorized faster.

What does SWFT require from software vendors?

The 2025 RFIs describe a third-party produced SBOM plus an independent assessment, and ask about SSDF attestation and automated risk artifacts. We found no final official artifact list as of 25 October 2026.

Is SWFT mandatory for DoD software vendors?

The 2025 RFIs describe the procedure as voluntary. We found no official document making it mandatory. Your contract and program office instructions are the binding source for any specific procurement.

Does SWFT replace RMF or the ATO process?

Nothing published says so. DoDI 8510.01 still governs authorization of DoD systems. SWFT aims to speed up authorizations by giving authorizing officials better product-level risk evidence.

How is SWFT different from continuous ATO?

Continuous ATO is a state a system reaches under the February 2022 cATO memo. SWFT focuses on the software products that go into systems and the evidence their suppliers provide.

What SBOM format should I use for a DoD customer?

SPDX or CycloneDX in JSON, following the CISA 2026 Minimum Elements, with a new SBOM for every release. Ask the program office if it prefers one.

Do I still need an SSDF attestation after OMB M-26-05?

M-26-05 removed the government-wide requirement for civilian agencies to collect attestations, but agencies may still use the attestation form and the SWFT Tools RFI asks about SSDF attestation directly. Expect to be asked, and keep the evidence ready.

How do I keep SWFT artifacts current without manual work?

Generate every artifact in the release pipeline, store it with the release, rescan stored SBOMs daily, and export from that store when asked.

Can I produce SWFT artifacts in an air-gapped environment?

Yes, if the scanner and its vulnerability data run inside and receive signed, dated feed updates. Record the feed date in every report.

Does Safeguard have a DoD authorization or SWFT approval?

No. Safeguard holds no DoD authorization; its architecture is designed for FedRAMP High, a design target, not an authorization. The assessment and risk decision belong to others.

A SWFT package is only as good as the vulnerability report inside it, and assessors will ask what you did about the findings that matter. The block below covers the ways Safeguard helps you close those findings in the open source components you ship, so the next release's package has fewer of them.

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, Griffin, Safeguard's security model, opens 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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. 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 local runner demo shows the setup from Step 1: you set up the runner on your own machine, approve it with its device code, and then scan from the terminal. For a defense vendor, the same flow is how you scan code that cannot leave a controlled network, with only the SBOM and findings going to the platform.

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

The CLI demo is a real session: install, run safeguard to open the interactive terminal, and ask it to "fix the lodash CVE in this repo." 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 approval, prints a summary and pushes nothing; then it shows /permissions, /model and /scan. In a SWFT context, that is how a finding in this release's vulnerability report becomes a reviewed fix before the next release's package is generated.

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

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

Quick check

Sources

• DoD CIO: Accelerating Secure Software memo (archive copy)
• SAM.gov: SWFT Tools RFI
• SAM.gov: SWFT External Assessment RFI
• SAM.gov: SWFT AI RFI
• NIST CSRC: DoD CIO SWFT presentation, July 2025
• AFCEA Signal: SWFT Initiative Makes Progress
• DoD: cATO memo, February 2022 (archive copy)
• DoDI 8510.01 (archive copy)
• OMB M-26-05
• CISA: 2026 Minimum Elements for an SBOM
• CISA: 2026 Minimum Elements PDF
• CISA bulletin, 29 July 2026
• NIST SP 800-218 SSDF
• NIST SP 800-218 PDF
• SLSA v1.0: Security levels
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System (EPSS)
• Safeguard docs: Generate SBOM
• Safeguard docs: EO 14028 Compliance Checks
• Safeguard docs: Portal Compliance
• Safeguard docs: Attestation and Signing
• Safeguard docs: Local Runner
• Safeguard docs: Air-Gapped Deployment
• Safeguard docs: Safeguard CLI
• Safeguard docs: CLI Usage
• Safeguard docs: Policies and Gates
• Safeguard docs: Vulnerabilities
• Safeguard docs: Reachability Analysis

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