CJIS Security Policy v6.1: Open Source Evidence for Public Safety Vendors

The current FBI CJIS Security Policy, version 6.1 dated 25 June 2026, requires systems that handle criminal justice information to install security updates within 15 days for critical flaws, 30 for high, 60 for medium and 90 for low, to scan for vulnerabilities at least monthly, and to keep a component inventory that records each piece of software's supplier, version and licence. Those duties sit with the agency, but they reach the software vendor through the contract and, where the vendor touches criminal justice information, the CJIS Security Addendum. In practice the vendor must show, per release, what components the product contains, which known vulnerabilities affect them, and how fast fixes ship.

This post covers the controls that matter for a vendor of records management, computer-aided dispatch, evidence management or court software, who audits what, what an agency asks for, and how to produce the evidence with Safeguard and with your own process.

Key takeaways

• Version confirmed on the FBI's own document. CJIS Security Policy version 6.1 is dated 06/25/2026 and incorporates the calendar year 2025 changes. Version 6.0, dated 27 December 2024, completed the move to a NIST SP 800-53 style structure.
• Priority 1 controls are sanctionable now. Since 1 October 2024, requirements that existed before modernisation and modernised requirements marked Priority 1 are the sanctionable set. Priority 2, 3 and 4 requirements sit in a zero-cycle that ends on 30 September 2027.
• Flaw remediation (SI-2), vulnerability monitoring (RA-5) and component inventory (CM-8) are all Priority 1. They apply to the agency's system, which includes the software you ship or host.
• Most supply chain and developer controls are Priority 2 or 3. They are not sanctioned yet, but agencies already write them into contracts.
• There is no CJIS certification for a product or a vendor. Each agency signs the CJIS Security Addendum with each contractor that performs criminal justice functions. Nothing here makes a product "CJIS certified".
• Safeguard capabilities covered, with maturity labels: SBOM generation and analysis (GA); software composition analysis and vulnerability management with EPSS and KEV (GA); reachability analysis (GA); policies and gates (GA, policy outcomes switched on per workspace); compliance and GRC suite with a NIST SP 800-53 framework page (GA); CLI and local runner (GA); on-prem and air-gapped deployment (GA); Zero AI mode (GA); autonomous remediation (GA, ships switched off with every category set to Manual); SAST (GA, not used as evidence here); fork and patch (GA).
• Keep criminal justice information out of the scanning flow entirely. Scan source, builds and release images, never a store that holds criminal justice information.

Scope and a caution

This post reads version 6.1 of the CJIS Security Policy (often called CJISSECPOL) as the FBI published it, plus NIST, CISA and FIRST sources. It is not legal or compliance advice. The agency, its Local Agency Security Officer and the state CJIS Systems Agency decide what compliance means for a given system, and your contract decides what you owe. The policy describes itself as the minimum standard and lets state, local, tribal, territorial and federal agencies add stricter requirements, so check your state's rules too.

What the current CJIS Security Policy says

Version 6.1 and what changed

The FBI's CJIS Division publishes the policy through its Security Policy Resource Center. The change management table in the 6.1 document lists:

The 6.1 summary of changes lists three Spring 2025 Advisory Policy Board topic papers that fix omissions and make corrections and additions to the modernised policy, plus administrative changes approved by the Security and Access Subcommittee on 14 November 2025. So 6.1 is a correction release on top of the 6.0 modernisation, not a new structure.

The structure is what matters to a vendor. The policy is now organised by NIST SP 800-53 control families: Configuration Management (CM), Risk Assessment (RA), System and Services Acquisition (SA), System and Information Integrity (SI), Supply Chain Risk Management (SR) and the rest. Each control has a CJIS statement, often with fixed values where NIST leaves a parameter to the organisation. If you have worked to NIST SP 800-53 Revision 5 for a federal customer, the names will be familiar. The values are not always the same.

California's CJIS Systems Agency told its subscribing agencies in a February 2025 bulletin that version 6.0 modernised the Assessment, Authorization and Monitoring, Personnel Security, System and Services Acquisition, and Supply Chain Risk Management families, and that FBI audits against 6.0 would start on 1 October 2025. Ask your own state's CSA which version its next audit cycle uses.

Priority markings and the zero-cycle

Section 1.4 of the policy explains which requirements are enforceable today:

• Requirements that existed before modernisation (version 5.9) stay auditable and sanctionable. Modernised controls that carry them forward are marked [Existing].
• Modernised requirements marked [Priority 1] have been sanctionable since 1 October 2024.
• Requirements marked Priority 2, 3 or 4 are in zero-cycle status, which began on 1 October 2024 and ends on 30 September 2027.

The List of Priorities at the front of the policy places every control, with an asterisk marking existing controls from version 5.9. California's bulletin described Priorities 2, 3 and 4 as a roadmap to implement in that order. A vendor that waits until October 2027 to think about SA-11 or SR-5 will meet them in a contract renewal first.

Flaw remediation: SI-2

SI-2 is marked [Existing] [Priority 1]. It requires the organisation to identify, report and correct system flaws; to test updates for effectiveness and side effects before installing them; to install security-relevant software and firmware updates within a fixed number of days "after the release of the updates" (critical 15, high 30, medium 60, low 90); and to fold flaw remediation into configuration management. The discussion text says testing decisions should consider whether updates come from authorised sources with appropriate digital signatures.

Enhancement SI-2(2), also Priority 1, requires vulnerability scanning tools to check whether components have the applicable updates installed at least monthly, or after any security incident involving criminal justice information or the systems that handle it.

Notice where the clock starts. For an agency running your product, the release is often your release. If an open source library in your dispatch application gets a critical fix upstream, the agency cannot install anything until you ship a build that contains it. Your release cadence becomes part of their compliance.

Vulnerability monitoring: RA-5

RA-5 is [Priority 1], with enhancements (2), (5) and (11). The base control requires the organisation to:

• monitor and scan for vulnerabilities in the system and hosted applications at least monthly, and when new vulnerabilities that may affect the system are reported;
• use tools built on standards for enumerating software flaws and measuring impact;
• analyse scan results;
• remediate legitimate vulnerabilities within the same 15, 30, 60 and 90 day windows as SI-2;
• share what monitoring finds so the same weakness gets fixed elsewhere;
• use tools that can readily update the vulnerabilities they scan for.

RA-5(2) requires the list of vulnerabilities to be updated within 24 hours before a new scan or when new vulnerabilities are reported. RA-5(5) covers privileged access for scanning components that hold criminal justice information. RA-5(11) is titled public disclosure program, and the RA-5 discussion describes a channel for receiving vulnerability reports from the public.

The discussion names CVE, the National Vulnerability Database, CWE and CVSS, and notes that custom software may need static, dynamic or binary analysis on top of scanning. That matters to a vendor. The agency's network scanner sees your product as a black box. It cannot see the open source packages compiled into your application. Only you can.

Component inventory: CM-8

CM-8 is [Priority 1], and so are enhancements (1) and (3). The control requires an inventory that accurately reflects the system, includes every component, avoids duplicate accounting, is detailed enough for tracking and reporting, and records date of installation, model, serial number, manufacturer, supplier information, component type, software owner, software version number, software license information, and hardware and physical location. It must be reviewed annually.

• CM-8(1) requires the inventory to be updated as part of installations, removals and system updates.
• CM-8(3) requires automated detection of unauthorised hardware, software and firmware, continuously or at least weekly.

CM-8 does not use the phrase software bill of materials, and it leaves granularity to what the organisation needs for tracking and reporting. That is the opening for a vendor: when an agency asks what is inside your product, a bill of materials per release is the natural answer.

Supply chain, acquisition and developer controls

The modernised SA and SR families are where vendor obligations become explicit:

SA-11 is written about the developer of the system or component. That is you. An agency cannot produce SA-11 evidence for your product; it can only ask you for it. SA-22's discussion lists alternative support for components the original developer has abandoned, including contracts with open source value-added vendors. If your product carries an end-of-life open source component, expect to replace it or show how it is still supported.

Who audits what, and where the vendor fits

The FBI CJIS Division. Its CJIS Audit Unit audits the CJIS Systems Agencies. The user agreement in the policy's appendices makes each CSA subject to a triennial audit by the CJIS Division.

The CJIS Systems Agency. There is one CSA per state or territory. Its CJIS Systems Officer administers the network and its Information Security Officer coordinates security across the user community. Each CSA completes a triennial audit of every agency that reaches FBI systems through it.

The local agency. The police department, sheriff's office, dispatch centre or court that uses your product. Its Local Agency Security Officer is the security contact with the CSA. The agency owns the system and its compliance.

The vendor. Under SA-9, a private contractor that performs criminal justice functions for an agency, or dispatching or data processing for a noncriminal justice government agency, gets access to criminal justice information only through an agreement that names its purpose and scope and incorporates the policy. Those contractors sign the CJIS Security Addendum certification page, meet the same training criteria as government staff doing similar work, and face the same extent of audit review as local user agencies.

SA-9 also requires agencies to audit external service providers with access at least triennially and to hold authority for unannounced inspections of provider facilities. A CSA may audit a contractor facility on behalf of another CSA and share the result. The Addendum itself binds the contractor to a security program consistent with the policy in force when the contract is signed and its later versions, lets the FBI perform a final audit after the Addendum ends, and can only be modified by the FBI.

If your product runs on the agency's servers and your staff never touch criminal justice information, you may not sign the Addendum. Your software is still a component of a system that handles it, so SI-2, RA-5 and CM-8 reach you through the agency.

What an agency asks a vendor for

At contract time

SA-4 tells agencies to put security requirements, documentation requirements and acceptance criteria into the contract. Expect some combination of:

• The Security Addendum where your people or hosted service can access criminal justice information, with signed certification pages.
• A security questionnaire mapped to the CJISSECPOL control families.
• A patch commitment: how fast you ship a fix after a vulnerability in your product or its components becomes known, sized to the agency's 15, 30, 60 and 90 day windows.
• A component list or bill of materials per release.
• A notification commitment for vulnerabilities and supply chain compromises, which SR-8 points toward.
• An end-of-support policy, because SA-22 makes the agency replace unsupported components.

Many states now add a cloud authorisation requirement on top. Our post on state government software procurement in 2026 covers that side.

At audit time

When the CSA audits the agency, the auditor samples. For controls that touch your software, expect requests for:

• the system inventory with versions and suppliers, and proof it was updated at the last change (CM-8, CM-8(1));
• recent monthly scan results and evidence that the vulnerability data was current (RA-5, RA-5(2), SI-2(2));
• for a sample of critical and high findings, the date the fix was released, the date it was installed, and the reason for any delay (SI-2, RA-5);
• records of how the agency received and acted on vendor advisories (SI-5).

The agency will turn to you whenever the finding sits inside your product. A per-release component list, a dated vulnerability history and release notes that name the fixed CVEs turn that request into minutes of work.

How fast flaws must be fixed, and how KEV changes the order

The windows

The policy sets the agency's window, not a separate vendor window, and you have to fit inside it. If a critical vulnerability is published in a library your product uses, and the agency has 15 days from your fixed release to install it, the useful question is how long you take to produce that release. A vendor that needs six weeks for a dependency update forces every agency customer into a documented exception.

So run two clocks: time from public disclosure to your fixed release, which you own, and time from your release to installation, which the agency owns. Publish the first and track it per release.

Where KEV fits

The CJIS Security Policy does not name CISA's Known Exploited Vulnerabilities catalog. SI-5 does tell agencies to receive alerts and advisories from external sources, and CISA is the first example it gives. CISA calls the KEV catalog "the authoritative source of vulnerabilities that have been exploited in the wild" and publishes it as CSV and JSON.

The federal directive tied to KEV changed this year. CISA's Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, was issued on 10 June 2026 and revoked BOD 22-01 and BOD 19-02. It sets remediation urgency from four factors: whether the asset is publicly exposed, whether the CVE is in KEV, whether exploitation can be fully automated, and whether exploitation gives partial or total control. Its timelines start when CISA adds a vulnerability to KEV or the agency finds it on an asset, whichever comes first, and the highest-risk cases also require forensic triage. BOD 26-04 binds federal civilian executive branch agencies, not state and local police, but CISA encourages every organisation to prioritise KEV entries.

For a public safety vendor, KEV does not shorten the CJIS window. Critical is still 15 days. KEV changes the order of work inside each window and the urgency of your notice to agencies. FIRST's Exploit Prediction Scoring System (EPSS) adds a daily probability, from 0 to 1, that a CVE will be exploited in the next 30 days. Use severity to set the window, KEV and EPSS to set the order, and reachability to check whether the vulnerable code runs in your product at all.

Our posts on SI-2 flaw remediation, RA-5 vulnerability scanning and how the two differ cover the NIST versions of these controls. If your contracts promise no known exploited vulnerabilities, see keeping a contract promise of no known exploited vulnerabilities.

What component inventory and supplier information to keep

CM-8's fields were written for an agency's asset register. Some only the agency can fill, others only the vendor can. Split them.

CISA's 2026 Minimum Elements for a Software Bill of Materials, published on 29 July 2026 and co-authored by CISA, NSA, the FBI and international partners, gives the current baseline for the vendor's half. It updates the 2021 NTIA minimum elements and adds elements such as component hash, component licence, SBOM tool name and version, SBOM generation context and an SBOM author signature. Its key action for buyers is to request SBOMs that meet the updated elements.

For each release you ship, keep:

1. A bill of materials in SPDX or CycloneDX, generated in the build that produced the release, covering direct and transitive dependencies and the contents of any container image you ship.
2. Component identifiers (package URL or CPE) so scanners can match each component to vulnerability data.
3. Hashes for the delivered artifacts, so the agency can check that what it installed is what you described.
4. Support status for each significant component, for SA-22.
5. The findings at ship time, your decision on each, and any exceptions with expiry dates.

Keep these per release, not per product. An agency running last year's version needs last year's list. Our post on CM-8 system component inventory covers the NIST control in more detail.

Keeping scanning inside the agency network

Some public safety software runs on agency premises: dispatch in a county data centre, evidence management in a sheriff's server room. The agency may not allow any data to leave. Three principles keep scanning compatible with that.

Scan software, not data. Composition analysis reads manifests, lockfiles, binaries and image layers. It has no reason to touch the database that holds incident reports, criminal history or evidence metadata. Put the line in writing: no scanner, runner or AI assistant is pointed at a store that holds criminal justice information.

Scan the release before it ships, then match by digest. Generate the bill of materials and findings in your own build environment for the exact artifact you deliver, and give the agency its digest. You can rescan that artifact daily in your environment as new CVEs appear, so the agency receives current evidence without anything running inside its network.

If the agency wants scanning inside its perimeter, use tools that work offline. That means a scanner that loads its vulnerability database from a file brought in through the agency's approved transfer process, sends nothing outbound, and is approved by the agency as a component of its own system.

How Safeguard does this job

Safeguard covers the software component half of the CJIS evidence: inventory per release, vulnerability matching with KEV and EPSS context, release gates, exception records, mapping to NIST SP 800-53 controls, and deployment options for restricted networks. It does not cover personnel, physical, encryption or incident reporting controls, and it holds no CJIS status. Everything below comes from Safeguard's documentation as of the review date.

Step by step

1. Decide what gets scanned. Map one Safeguard project to each shippable component: application repositories, the container images you deliver, and SBOMs you receive from suppliers. Exclude every system that holds criminal justice information, and record that decision in your security plan.

2. Install the CLI and sign in (CLI, GA). The docs show:

   # macOS and Linux
   curl -fsSL https://cli.safeguard.sh/install | bash
   
   # open the interactive terminal, then type /login
   safeguard
   

   On Windows the docs show irm https://cli.safeguard.sh/install.ps1 | iex. The CLI is a single static binary, and a machine is authorised by signing in once.

3. Generate the bill of materials and findings in your build (SBOM generation and analysis, GA; SCA, GA). The usage docs show one target per scan:

   # your source tree
   safeguard scan --dir .
   
   # the container image you deliver
   safeguard scan --image myregistry.azurecr.io/myapp:v1 \
     --registry-username "$REGISTRY_USER" \
     --registry-password "$REGISTRY_PASSWORD"
   
   # an SBOM you received from a supplier (SPDX or CycloneDX)
   safeguard scan --sbom sbom.json
   

   Results land as JSON under ./output, including vuln.json and license.json. Safeguard's SCA resolves the dependency graph from manifests and lockfiles across npm, pnpm and Yarn, PyPI, Maven and Gradle, Go modules, Cargo, NuGet, Composer and Ruby Bundler, plus components inside container image layers. 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. Gating happens in the platform (step 7).

4. Check the SBOM before it goes to an agency. The CLI validates CycloneDX, SPDX and VEX documents against their specifications, and --strict treats warnings as errors:

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

   Schema validity and minimum element coverage are different tests, so also check against CISA's 2026 Minimum Elements.

5. Bring results into the platform without moving source code (local runner, GA). Scanning from the interactive terminal with /scan . while signed in uploads the SBOM and findings; the docs say source never leaves the machine. The runner is part of the CLI. It polls the platform for jobs assigned to that machine, runs them locally and uploads only results, over outbound HTTPS that it opens itself. On a build server:

   safeguard runner start --workspace ./path/to/repo
   safeguard runner status
   safeguard runner stop
   

   On networks that forbid held connections, --poll-wait 0 switches to fixed-interval polling.

6. Read findings with KEV, EPSS and reachability context (vulnerability management, GA; reachability analysis, GA). Each SCA finding carries the component and version, CVE or GHSA identifiers, severity with EPSS and KEV context, the transitive path from your project root, a reachability verdict where available, and the safe upgrade target. The Vulnerabilities tab groups findings as Critical, High, Medium, Low and Exploitable, and filters by severity, CVSS, EPSS, exploitable status, fix availability, reachability and date. Data sources listed in the docs include NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins. The docs list static reachability for Ruby and PHP, and all reachability for Swift and Objective-C. Safeguard's docs say reachability filtering cuts open findings by 60 to 80 percent; treat that as their stated figure, not a promise for your code.

7. Keep watching shipped releases. The docs describe daily continuous scanning: when new CVEs are published, projects are re-evaluated automatically. As long as each supported release stays a project version in Safeguard, a CVE published next month against a component in last year's build shows up against that build. That answers RA-5's on-disclosure clause and RA-5(2)'s fresh data requirement for your product.

8. Gate releases on the agency's windows (policies and gates, GA). Under Settings → Policies, choose Create Policy and define conditions in the visual builder or YAML. Documented conditions include vulnerability severity, CVSS, EPSS, licence, component age, maintenance status and SLSA level. Each policy's action is Block (gate fails), Warn (passes with a warning) or Notify (passes and sends a notification). With policy outcomes on for your workspace, the docs show:

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

   Gates are evaluated by the platform on scans of connected repositories, not by a local scan. A reasonable starting set for CJIS customers: block on critical, warn on high, and block on abandoned packages so SA-22 problems surface before release. KEV and reachability are filters on findings rather than listed gate conditions, so use them to order work.

9. Record every exception with an expiry. Request Exception takes the policy and finding, a business justification and an expiration date, then routes to approvers with an audit trail. On the Vulnerabilities tab, Accept Risk works the same way, and Mark False Positive takes a justification. These records answer the auditor's question about a missed 15 day window before it is asked, and feed the agency's own plan of action.

10. Open fix pull requests (autonomous remediation, GA). AI Remediate on the Vulnerabilities page has Griffin generate remediation plans for review and open pull requests that move dependencies to fixed versions. Autonomous remediation ships switched off, with every category set to Manual, so a person approves each change unless you choose otherwise. The pull request starts the SI-2 trail: fix, test, release, notify.

11. Map the evidence to NIST SP 800-53 (compliance and GRC suite, GA). The NIST SP 800-53 framework page is on in each workspace unless you switch it off under Compliance › Manage. It defines seven scan requirements, each decided by a scan of the product's inventory: CM-8 (inventory reflects the system), CM-8(3) (each component recorded with name and version), SI-7 (hashes for delivered components), SR-4 (provenance, including who created the inventory), SR-3 (supplier of each component recorded), RA-5 (package URL or CPE identifiers) and SI-2 (known versions for every component). The Controls tab adds catalogue controls including RA-5, SI-2 and SR-3, which you can evidence with tests, uploads, policies or an attestation. There is no CJIS framework page, so keep your own crosswalk to the CJIS values.

12. Answer the AI question up front (Zero AI mode, GA). Safeguard can run with no language model anywhere in the loop, and every scanner still works. Bringing your own approved model, or running Safeguard's models inside your environment, are the other options. Offer this to agency security officers before they ask.

13. Scan inside a restricted or air-gapped network (on-prem and air-gapped deployment, GA). For a single machine, the CLI docs show safeguard update --import to load a vulnerability database downloaded elsewhere. For a full platform inside a perimeter, the air-gapped docs describe signed snapshot bundles carrying vulnerability feed deltas (NVD, GitHub Advisory, OSV, CISA KEV and daily EPSS), delivered by one-way diode, signed removable media, a short scheduled sync through a DMZ, or a pull replica, on a cadence from hourly to quarterly. A receiver in the DMZ verifies signatures, and no component inside the perimeter calls outbound. Leave optional lookups that call external services, such as the CLI's --resolve-transitive flag, switched off where outbound traffic is forbidden.

Requirement, what Safeguard does, what you still own

Evidence that comes from somewhere else

Personnel security. PS-3 requires state of residency and national fingerprint-based record checks before people are given access to the system. For a vendor, that means staff who support a hosted system or touch production data. Signed Addendum certification pages sit with the agency for audit.

Training. Contractors performing criminal justice functions meet the same training criteria as government staff doing similar work.

Encryption. The communications protection controls in version 6.1 call for certified cryptographic modules and symmetric keys of at least 256-bit strength in the cases the policy describes. Read the SC-8, SC-13 and SC-28 text for your architecture; module certification evidence comes from your cryptographic library or platform provider.

Identity, physical and media protection. Multi-factor authentication, account management, data centre controls and media sanitisation come from your identity provider, hosting arrangements or the agency's premises.

Incident reporting. IR-6 (Priority 2) requires suspected incidents to be reported immediately, and no later than one hour after discovery, then onward to the CSA's officials and the FBI CJIS ISO. Your contract should say how you report to the agency inside that hour.

Your secure development process. NIST SP 800-218, the Secure Software Development Framework, gives agencies a shared vocabulary: PS.3.2 for collecting and sharing provenance data for each release's components, RV.1 for identifying and confirming vulnerabilities on an ongoing basis, and RV.2 for assessing, prioritising and remediating them. Our post on proving secure software development to a federal contracting officer maps those practices to evidence.

What Safeguard does not do

• It does not make anything CJIS compliant, certified or approved. There is no FBI certification for products or vendors, and Safeguard has never been audited under CJIS. On Safeguard's own posture: it is SOC 2 Type II compliant, and its architecture is designed for FedRAMP High, which is a design target, not an authorisation.
• It must never receive criminal justice information. The flows above scan source, build artifacts, images and SBOMs. Do not connect Safeguard to databases, file shares, evidence stores or logs that contain it, and do not paste it into the CLI assistant or any AI tool.
• It has no CJIS framework page. The NIST SP 800-53 page is a working map. The CJIS windows, monthly scan floor and priority markings are not modelled, so you keep that crosswalk.
• It does not scan the agency's network or hosts. RA-5 for servers, workstations, mobile data terminals and network devices needs the agency's own scanning.
• It does not cover personnel, physical, encryption or incident reporting controls.
• It does not install patches at the agency. It can open the pull request that fixes your dependency and help prove the release is clean. The agency still installs it.
• Some features are not at full depth. SAST is generally available, so this post does not offer it as evidence for RA-5's custom software analysis. Fork and patch is generally available.
• Gates are platform-side. A local safeguard scan writes results but does not gate, and policy outcomes are switched on per workspace.

Common mistakes

Treating CJIS as a certificate. Agencies and CSAs know there is no "CJIS certified" product, and the phrase undermines the rest of your answers. Say what you do: sign the Addendum where required, meet the contract's controls, provide evidence.

Answering RA-5 with the agency's network scan. A network scanner sees open ports, not the logging library compiled into your application. Component evidence has to come from you.

One inventory per product instead of per release. Agencies run different versions, and an auditor will ask about the one installed.

Starting the clock at the agency. If your fixed release takes 45 days, a 15 day critical window is already gone for every customer.

Ignoring Priority 2 because it is not sanctioned yet. SA-11, SA-22, SR-5 and SR-6 already appear in contracts, and the zero-cycle ends on 30 September 2027.

Letting tooling near criminal justice information. Pointing an assistant or scanner at a production database turns an evidence exercise into an exposure.

Copying NIST values into a CJIS answer. NIST leaves many values to the organisation; CJISSECPOL fixes them. Quote the CJIS values.

FAQ

What is the current version of the CJIS Security Policy?

Version 6.1, dated 25 June 2026, published by the FBI CJIS Division. It incorporates the calendar year 2025 changes. Version 6.0, dated 27 December 2024, completed the move to a NIST SP 800-53 style structure. Ask your state CSA which version applies to your next audit.

Is there such a thing as CJIS certification for software?

No. The FBI does not certify products or vendors. Agencies remain responsible for compliance, CSAs audit agencies, and the FBI audits CSAs. Contractors that perform criminal justice functions sign the CJIS Security Addendum with each contracting agency.

How fast does CJIS require critical vulnerabilities to be patched?

SI-2 requires security updates to be installed within 15 days of release for critical, 30 for high, 60 for medium and 90 for low. RA-5 sets the same windows for remediating vulnerabilities. Both are Priority 1 and sanctionable.

How often does CJIS require vulnerability scanning?

RA-5 requires scanning at least monthly and when new vulnerabilities that may affect the system are reported. SI-2(2) requires a monthly check of update status, or after an incident. RA-5(2) requires vulnerability data to be updated within 24 hours before a scan.

Does the CJIS Security Policy require an SBOM?

It does not use the term. CM-8 requires a component inventory with supplier, version and licence information at the granularity needed for tracking. For components inside a vendor's product, a per-release SBOM is the practical way to supply that, and CISA's 2026 Minimum Elements set the content baseline.

Do software vendors have to sign the CJIS Security Addendum?

Contractors that perform criminal justice functions, or dispatching and data processing for a noncriminal justice government agency, need an agreement that incorporates the policy and must sign the Addendum certification page. A vendor whose staff never access criminal justice information may not, but its software still has to meet the policy as part of the agency's system.

Does CJIS require using the CISA KEV catalog?

It does not name the catalog. SI-5 requires agencies to receive and act on alerts from external sources and lists CISA first. KEV is the practical way to decide which vulnerabilities go first inside the CJIS windows.

Who audits a vendor for CJIS?

The agency, and the CSA on its behalf. SA-9 requires agencies to audit external service providers with access at least triennially and to hold authority for unannounced inspections. A CSA can audit a contractor facility for another CSA, and the FBI may perform a final audit after the Addendum ends.

Getting the evidence ready before the next audit cycle

Start with the release you will ship next: generate its bill of materials in the build, check it against CISA's 2026 Minimum Elements, record findings with KEV and EPSS context, and write down your time from disclosure to fixed release. Then work back through the versions your agency customers still run. To try the flow, download the CLI from safeguard.sh/download and follow the Safeguard docs. For release gating in more depth, see proving every production release passed a security gate.

The CJIS windows assume a fix exists and that you can ship it quickly. The section below covers what Safeguard offers when the fix is slow to reach your build, or when upstream has not produced one at all.

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

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 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. A public safety vendor uses the same pattern on a build server, where the scan runs locally and only the SBOM and findings reach the platform, never source code and never anything from an agency system.

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

The second demo is a real CLI session. After install, safeguard opens the interactive terminal and the user asks 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 approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. For a CJIS customer, this is the first step of the SI-2 trail: a tested dependency fix that a person approves before it becomes a release.

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

Quick check

Sources

• FBI CJIS Division: Criminal Justice Information Services (CJIS) Security Policy, Version 6.1, 06/25/2026 (PDF)
• California Department of Justice: Information Bulletin 2025-ISRS-001, CJIS Security Policy Version 6.0 (PDF)
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: Release 5.2.0 of SP 800-53 controls
• NIST: SP 800-218, Secure Software Development Framework Version 1.1
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA and partners: 2026 Minimum Elements for a Software Bill of Materials (PDF)
• FIRST: Exploit Prediction Scoring System (EPSS)
• Safeguard Docs: Software Composition Analysis
• Safeguard Docs: Vulnerabilities
• Safeguard Docs: Policies and Gates
• Safeguard Docs: NIST SP 800-53 framework
• Safeguard Docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard Docs: Local Runner
• Safeguard Docs: Safeguard CLI
• Safeguard Docs: CLI Usage
• Safeguard Docs: Air-Gapped Deployment

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