GovRAMP and TX-RAMP: Vulnerability Evidence for SaaS Vendors

GovRAMP, the program formerly called StateRAMP, expects a SaaS vendor with a Ready, Provisionally Authorized or Authorized status to scan its whole system boundary at least monthly, submit raw machine-readable results with an updated inventory and a POA&M, and fix high-risk vulnerabilities within 30 days, moderate within 90 and low within 180. TX-RAMP, run by Texas DIR for state agencies, asks Level 2 services for quarterly vulnerability reports and Level 1 services for annual ones, with counts by CVSS severity and plans for every high and critical item. Neither program's scanner list says anything about the open source components inside your application, which is where a lot of your findings actually live.

This post is for the compliance or security lead at a US SaaS company selling to state agencies, cities, counties, school districts and public universities, including Texas. It covers what each program requires today, which NIST SP 800-53 controls carry the vulnerability work, what goes into the monthly package and the POA&M, how component findings fit next to infrastructure scans, and how to produce the software component half of the evidence with Safeguard and with your own process.

Key takeaways

• GovRAMP is StateRAMP under a new name. GovRAMP's Security Assessment Framework, version 4.2, adopted 21 April 2026, calls the organization "StateRAMP dba GovRAMP".
• GovRAMP continuous monitoring is monthly for Ready, Provisionally Authorized and Authorized, quarterly for Core. The Continuous Monitoring Guide and Escalation Process, version 2.0, adopted 1 June 2026, sets 30, 90 and 180 day remediation windows for high, moderate and low risk vulnerabilities.
• TX-RAMP Program Manual 4.0 took effect on 12 February 2026. Level 2 services report vulnerabilities quarterly and Level 1 services annually, through DIR's SPECTRIM portal, using NVD CVSS severity bands.
• A GovRAMP status can carry over to Texas. Manual 4.0 grants TX-RAMP Level 2 certification to services with GovRAMP Core, Ready, Provisionally Authorized or Authorized status, and such services send their monitoring to GovRAMP rather than to TX-RAMP.
• The controls that matter are CM-8, RA-5, SI-2, SR-3, SR-4 and SI-7. Both programs build on NIST SP 800-53 Rev. 5.
• KEV changes the order of work, not the written windows. Neither program's documents fix a KEV deadline for vendors. GovRAMP can issue out-of-cycle data calls based on CISA guidance, and FedRAMP, the model both programs borrow from, now ties KEV remediation to CISA BOD 26-04.
• Safeguard capabilities covered, with maturity labels: SBOM generation and analysis (GA), including scheduled and continuous scanning; software composition analysis and vulnerability management with EPSS and KEV (GA); reachability analysis (GA); policies and gates (GA); compliance and GRC suite with a StateRAMP framework page (GA); CLI (GA); bulk data export (GA); autonomous remediation (GA, ships switched off with every category set to Manual); fork and patch (GA); desktop app. SAST and DAST are generally available and are not part of this flow.
• Safeguard holds no GovRAMP, TX-RAMP or FedRAMP status and is not an assessor. It produces component evidence that goes into your package.

Scope and a caution

This post reads the GovRAMP and TX-RAMP program documents, NIST SP 800-53 Rev. 5, and CISA and FedRAMP sources, all checked on 25 October 2026. It is not legal or compliance advice. Your 3PAO, the GovRAMP PMO, the TX-RAMP team and each contracting agency decide your obligations, and agencies can add requirements by contract.

What GovRAMP and TX-RAMP are today

GovRAMP is the program formerly called StateRAMP

GovRAMP is a 501(c)(6) nonprofit, chartered in April 2020, that verifies the security of cloud products sold to state and local government, K-12, public higher education, special districts and critical infrastructure organizations.

The rename is recorded in GovRAMP's own documents. The Security Assessment Framework (SAF) shows version 4.1, dated 20 September 2025, as "Updated to reflect DBA", and the current text says "StateRAMP dba GovRAMP". The scan guide (version 1.2, March 2026) and the monitoring guide (version 2.0, June 2026) were both revised for the rebrand. Older contracts and RFPs say StateRAMP; both names mean the same program.

The technical basis has not changed. The SAF says GovRAMP's verification model is based on NIST SP 800-53 Rev. 5, and defines three impact levels aligned with the FedRAMP Rev. 5 Low, Moderate and High control baselines. Providers had until 1 October 2024 to move their packages from Rev. 4 to Rev. 5.

GovRAMP statuses and what each asks of monitoring

GovRAMP offers two assessment products that are not verified statuses, and four that are. The difference matters because only verified statuses carry formal continuous monitoring.

Core, Ready, Provisionally Authorized and Authorized products appear on GovRAMP's Authorized Product List. The SAF also offers a Fast Track, with no new audit, for products that already hold certain FedRAMP statuses.

TX-RAMP is Texas's own program

TX-RAMP, the Texas Risk and Authorization Management Program, is run by the Texas Department of Information Resources (DIR). The Program Manual, version 4.0, effective 12 February 2026, says state agencies may only enter or renew contracts for cloud computing services that comply with TX-RAMP. "State agency" here includes universities and other institutions of higher education. "Cloud computing service" follows the NIST SP 800-145 definition, so infrastructure, platform and software services are all in scope.

Two administrative details have moved recently, and DIR's own pages do not yet agree on them:

• The statute. Manual 4.0 cites Government Code Section 2063.408. DIR's FAQ page still cites Section 2054.0593, the original section created by Senate Bill 475. A footnote in the manual explains that House Bill 150 (2025) created the Texas Cyber Command and transfers DIR's cybersecurity duties, including TX-RAMP, to it. DIR keeps running the program until a memorandum between the two bodies moves the remaining duties. Expect the program owner and contact addresses to change during the life of your certification.
• Provisional certification length. Manual 4.0 says provisional certification lasts 12 months. DIR's FAQ still says 18 months and still names version 3.0 as the current manual. The manual is the newer and more specific document; check with the TX-RAMP team before planning around either figure.

TX-RAMP has three certification types:

DIR reviews submissions itself, so TX-RAMP does not require a 3PAO, and the FAQ says there is no fee. Level 1 and Level 2 certifications last three years. A Fast Track route accepts DIR-approved third-party reports such as SOC 2 Type 2, ISO 27001 and HITRUST.

When a state agency asks for each

GovRAMP applies when a government buyer writes it into its procurement rules or a solicitation, so ask early in every deal which status and impact level the buyer will accept, and by when.

TX-RAMP is a statutory requirement for Texas state agencies and higher education institutions buying cloud services, and the contracting agency sets the minimum level. Texas local governments are not state agencies under the definition the manual cites, though some ask for it anyway.

The two connect directly. Manual 4.0 grants TX-RAMP Level 2 certification to services with a GovRAMP Core, Ready, Provisionally Authorized or Authorized status, and says that wherever it says GovRAMP it also means StateRAMP. A GovRAMP Snapshot only earns provisional certification, and a service in the Progressing Snapshot Program keeps provisional certification while it stays enrolled. Since 30 October 2024, according to DIR's FAQ, GovRAMP and FedRAMP products are no longer added to the TX-RAMP list automatically; you must file a reciprocity request.

For a live explainer on GovRAMP itself, see what GovRAMP is and when a state buyer asks for it. For the wider buying process, see state government software procurement in 2026.

Which controls cover inventory, scanning, flaw remediation and supply chain

Both programs inherit their control language from NIST SP 800-53 Rev. 5. NIST's machine-readable catalog is at release 5.2.0. These are the controls that carry the vulnerability evidence job, in NIST's words summarised:

CM-8 System Component Inventory. Keep an inventory that accurately reflects the system, includes every component, avoids double counting and is granular enough for tracking, and review it on a set schedule. GovRAMP turns this into a monthly inventory workbook, and its scan guide rejects scans that cannot be matched to inventory rows.

RA-5 Vulnerability Monitoring and Scanning. Scan "the system and hosted applications" on a set frequency and when new vulnerabilities are reported, analyse the results, remediate on a defined schedule, and keep the scanners' vulnerability data current (RA-5(2)). The words hosted applications are the hook for component scanning: the libraries inside your application are in scope.

SI-2 Flaw Remediation. Identify, report and correct flaws, test updates before installing them, install security updates within a defined period of release, and tie remediation to configuration management. SI-2(2) adds automated checks that components have the updates installed.

SR-3 and SR-4. Run a process to find and address supply chain weaknesses, and document and maintain the provenance of components. Knowing who supplies each component is the start.

SI-7 Software, Firmware and Information Integrity. Detect unauthorised changes to software. Component hashes are the practical evidence.

GovRAMP's baselines follow FedRAMP Rev. 5, which include the Supply Chain Risk Management (SR) family, and its monitoring guide requires an annual Supply Chain Risk Management Plan. The control family table in TX-RAMP Manual 4.0's Appendix A has no SR row, so in most Texas deals SR evidence is a GovRAMP or contract question. Check the baseline workbook for your level.

For deeper reads on single controls, see our posts on NIST 800-53 RA-5, SI-2 flaw remediation and CM-8 component inventory.

What monthly continuous monitoring involves

The GovRAMP monthly package

GovRAMP's Continuous Monitoring Guide bases its program on NIST SP 800-137. Monitoring starts when a product receives a verified status. Your continuous monitoring plan is validated by your 3PAO for Ready, Provisionally Authorized and Authorized, or by the GovRAMP PMO for Core.

For a system with a Low or Moderate categorisation, the guide lists the monthly uploads to the GovRAMP document repository:

1. POA&Ms.
2. An updated inventory workbook.
3. Operating system, database and web application vulnerability scans.
4. Compliance scan results, meaning configuration hardening checks against a named benchmark.
5. Risk adjustments.
6. Operational requirements.
7. False positives.
8. A deviation request form, when any of the three items above applies.
9. An executive summary covering all of the above.

Raw vulnerability and compliance scan results must be machine readable, such as CSV or XML. For High systems, the PMO arranges a monthly review process with the provider. You also confirm your own staff's access to the GovRAMP repository each month.

The PMO checks that POA&Ms account for past-due items, that fixes are on time with evidence, that late items carry a justification, that every scan covers every inventory component, and that risk adjustments, false positives and operational requirements are documented.

The Vulnerability Scan Requirements Guide adds quality rules: authenticated scans, all plugins on, the full system boundary, current signatures, and every finding on the monthly POA&M. Raw files go in as CSV or Excel with executive, detailed and inventory summaries. Scans and inventory that cannot be matched by IP address, system name or another unique identifier are rejected.

Each year the 3PAO assesses about a third of the controls and scans web applications, databases and operating systems; Provisionally Authorized and Authorized products also get an annual penetration test.

The FedRAMP version of this process is covered in our post on what FedRAMP continuous monitoring really involves.

What goes in a POA&M

The SAF describes the POA&M as the provider's plan and schedule to fix each weakness, and as the vulnerability tracking system shared by the provider, the PMO and authorizing bodies. Use GovRAMP's template, because the PMO reviews against it. For a software component finding, a useful row records:

• CVE or advisory ID, component and version, and where it sits (service, image, release).
• The source and date of first detection, which starts the clock.
• Severity, plus any adjustment with a rationale.
• Target version, owner and milestone dates.
• Closure evidence: the release that shipped the fix and a clean rescan.
• For anything late, a deviation request (risk adjustment, operational requirement or false positive) with reasoning.

TX-RAMP uses the term differently. Manual 4.0 says TX-RAMP requires POA&Ms only for control deficiencies, not for individual vulnerabilities, and that providers revisit them at least quarterly. Individual vulnerabilities go into the separate vulnerability report.

TX-RAMP's vulnerability report

For a TX-RAMP certified service, the manual sets the minimum. Level 2 services report quarterly and Level 1 services annually, through SPECTRIM, which then shares the report with agencies that contract for the service. The report should cover the assets used to deliver the certified service, "to include application, database, and infrastructure vulnerabilities where applicable". Severity follows the current NVD CVSS version.

If you are not remediating a high or critical item, describe the mitigation. TX-RAMP can increase reporting frequency, request evidence without notice, or revoke certification if vulnerabilities are not addressed "within the prescribed timelines". Breaches of system security must be reported to TX-RAMP within 48 hours. Services certified through GovRAMP or FedRAMP reciprocity do not file these reports with TX-RAMP; their monitoring goes through the other program.

How software component findings differ from infrastructure scan findings

The GovRAMP scan guide's tool list is operating system and network scanners, database scanners and web application scanners. Those see hosts, databases and running endpoints.

They see the open source libraries in your application poorly or not at all. An authenticated host scanner reports packages installed by the operating system's package manager, but usually not a JavaScript dependency bundled into your front end, a Java library shaded into a JAR, a Python wheel in a container layer, or a Go module compiled into a binary. A web application scanner may never trigger the vulnerable path. Yet RA-5 covers hosted applications and TX-RAMP's report explicitly includes application vulnerabilities.

Four practical differences follow:

1. Identity. Infrastructure findings key on IP address or hostname. Component findings key on a package URL or CPE, a version, and the artifact that contains it. To pass GovRAMP's matching rule, each component finding must point to an inventory row: the container image, service or host that ships the library.
2. Counting. One vulnerable library baked into a base image can appear on every host built from it. If you feed both host and image results in raw, the same CVE is counted many times. GovRAMP's deficiency triggers count unique vulnerabilities, so decide how you deduplicate and state it in the executive summary.
3. Fix path. A host finding is fixed by patching or rebuilding a host. A component finding is fixed by changing a manifest or lockfile, rebuilding the artifact, testing and redeploying. The milestone dates in your POA&M should reflect a release cycle, not a patch window.
4. Timing. A host scan runs on a monthly schedule. A component can become vulnerable on any day a new advisory is published, with no change to your code. The finding exists from that date, whether or not your monthly scan has noticed yet.

The simplest structure that works: keep infrastructure scans as the program expects, and add a component section to the monthly package with its own machine-readable results, each row tied to an inventory component, and the same findings carried onto the POA&M.

Remediation timelines by severity, and how KEV changes them

GovRAMP: 30, 90 and 180 days

The Continuous Monitoring Guide says the provider must remediate high-risk vulnerabilities within 30 days, moderate within 90 and low within 180, unless an applicable control sets a shorter period; it gives RA-5 under the CJIS overlay as an example. The guide sets no separate window for critical, so treat criticals as high-risk (30 days at most) unless your 3PAO or a contract says otherwise.

Late items trigger escalation. The guide's deficiency triggers include:

After a Corrective Action Plan come suspension, noted on the public product list, and revocation. A sudden jump in component findings, such as a new advisory against a library every service uses, can push your unique count past the 20% trigger in one month. You can ask the PMO to rebaseline with a justification.

TX-RAMP: severity bands and your contracts

Manual 4.0 does not set fixed remediation days for vendors. It asks for counts by CVSS band and plans for high and critical items, and reserves the right to act if vulnerabilities are not addressed within prescribed timelines. In practice the timelines come from your contracts with agencies, from your own policy, and, for services certified through GovRAMP, from GovRAMP's guide. Write your own windows into your security plan so there is something to measure against.

Where KEV fits

CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities known to be exploited in the wild. CISA's page says organizations "should use the KEV catalog as an input" to their prioritisation. Neither GovRAMP's nor TX-RAMP's documents set a KEV deadline for vendors, but there are three reasons to treat KEV listings as first in line:

• GovRAMP data calls. The monitoring guide lets the PMO issue an out-of-cycle data call for a widely used vulnerable product, with accelerated timelines based on CISA or similar guidance. You will need to say quickly which services and releases contain the component.
• FedRAMP has moved. CISA's BOD 26-04, issued 10 June 2026, revoked BOD 22-01 and BOD 19-02 for federal civilian agencies and sets timelines from four factors: asset exposure, KEV status, exploit automation and technical impact. FedRAMP's notice NTC-0014 says its 2026 vulnerability detection and evaluation rules become mandatory on 7 December 2026, that KEV remediation follows BOD 26-04, and that the legacy monthly scanning process is not enough for BOD 26-04 assurance. GovRAMP models itself on FedRAMP, so watch for its guides to follow; until then its 30, 90 and 180 day windows are the written rule.
• Agency contracts. Many state contracts now say "no known exploited vulnerabilities". Our sibling post on keeping a contract promise of no known exploited vulnerabilities covers that wording.

A workable rule: fix KEV-listed components that are reachable from your code ahead of everything else, inside the 30 day window and usually much sooner, and record in the POA&M when the KEV listing was added, because it changes the risk rating.

How one evidence set can serve several states

The sensible approach is to build one evidence set to the strictest program you sell into and present it in each program's format.

• Use GovRAMP Moderate as the base when you can. It follows FedRAMP's Moderate baseline, and a GovRAMP verified status already earns TX-RAMP Level 2 by reciprocity.
• Run monthly, report at each cadence. A TX-RAMP quarterly report is three months of the same data grouped by CVSS band.
• Keep one inventory with one identifier per component. The GovRAMP workbook, the TX-RAMP inventory questionnaire and agency SBOM requests all draw on it.
• Use the strictest window. If a contract says 15 days for critical and GovRAMP says 30, track that service to 15.
• Share through the programs. GovRAMP can give participating governments access to your monthly summary, and SPECTRIM shares TX-RAMP reports with contracting agencies.

Several states also ask for SBOMs directly. Our post on state and local government SBOM mandates tracks those, and the sibling post on IRS Publication 1075 evidence for state agency vendors covers a federal overlay that often rides on the same contracts.

How Safeguard does this job

Safeguard covers the software component half of this evidence: inventory per service and release, scheduled and continuous vulnerability matching with KEV and EPSS context, release gates, exception records, mapping to the StateRAMP requirements, and exports for the monthly package. It does not run operating system, database, network or compliance configuration scans, and it is not a 3PAO. Everything below comes from Safeguard's documentation as of the review date.

One naming note: Safeguard's docs still call the framework page StateRAMP. It is the same program as GovRAMP.

Step by step

1. Map your authorization boundary to Safeguard projects. Each service repository and container image in your boundary becomes a Safeguard project, versioned to what you deploy and named as in your GovRAMP inventory workbook.

2. Connect source and images (SBOM generation and analysis, GA). Under Integrations, connect repositories from GitHub, GitLab, Bitbucket or any Git URL, and images from registries such as Amazon ECR, Docker Hub or any OCI registry, choosing branch or tag, project name and version for each. The Projects table then shows each project's version and finding counts by Exploitable, Critical, High, Medium and Low.

3. Or scan from the build with the CLI (CLI, GA). The docs show install and scan commands:

   # Install the CLI
   curl -fsSL https://cli.safeguard.sh/install | bash
   
   # Open the terminal, then type /login and /scan .
   safeguard
   
   # Or scan from the command line, writing results under ./output
   safeguard scan --dir .
   

   The usage docs show one target per scan, including the images you deploy and SBOMs you receive from suppliers:

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

   Results land as JSON files under ./output, including vuln.json and license.json. A scan from the interactive terminal while signed in uploads the SBOM and findings to the platform, and the docs say your source never leaves the machine. 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.

4. Turn on scheduled scanning (continuous scanning, GA). The docs say Safeguard scans all projects daily and re-evaluates them automatically when new CVEs are published. You can add triggers: On Push, Scheduled (daily, weekly or custom) and On Release when new tags are created. The continuous scanning page also describes rescans when vulnerability feeds change, including KEV additions and EPSS score changes. That covers RA-5's "when new vulnerabilities are identified" clause for components, between your monthly cycles. That page carries a banner saying its /v1 API endpoints are not yet available, so use the in-app settings, not the API.

5. Switch on the StateRAMP framework page (compliance and GRC suite, GA). The page is on in each workspace unless you switch it off in Compliance › Manage. It defines six scan requirements, each decided by a scan of the product's inventory:

   Requirement	What a scan checks
   STRAMP-CM-8 System Component Inventory	The inventory reflects the system's components
   STRAMP-RA-5 Continuous Vulnerability Scanning	Components carry identifiers that can be matched to vulnerability databases
   STRAMP-SR-4 Supply Chain Documentation	Provenance is documented, including who produced the inventory
   STRAMP-SR-3 Supplier Identification	The supplier of each component is identified
   STRAMP-SI-7 Software Integrity	Components have hashes
   STRAMP-SI-2 Flaw Remediation Data	Every component has version data so patch applicability can be decided

   The framework's Controls tab adds catalog controls, including monthly vulnerability scanning, continuous monitoring and reporting, incident reporting to the state CISO and PMO, and maintaining the System Security Plan. You evidence those with tests, uploaded documents, policies or an attestation. The page also offers policy templates, some written for the program. There is no TX-RAMP page, so keep your own short crosswalk.

6. Read findings with KEV, EPSS and reachability context (vulnerability management, GA; reachability analysis, GA). The Vulnerabilities tab groups findings as Critical, High, Medium, Low and Exploitable. Each shows CVE ID, CVSS, EPSS, whether it is exploited in the wild, component and version, fixed version and reachability, and you can filter on each, plus date. Listed data sources include NVD, GitHub Security Advisories, OSV and CISA KEV. Reachability shows whether your code calls the vulnerable function. CVSS bands map straight onto TX-RAMP's table.

7. Gate releases on your 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 score, EPSS score, license, component age and maintenance status. Each policy's action is Block (the gate fails), Warn (passes with a warning naming the policy) or Notify (passes and sends a notification). Gates are evaluated by the platform on scans of connected repositories. With policy outcomes on for your workspace, the docs show:

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

   A reasonable start: block on critical, block on high with a fix available, warn on medium, and block abandoned packages.

8. Record exceptions the way GovRAMP expects them (policies and gates, GA; vulnerability management, GA). 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 takes an expiration date and justification, and Mark False Positive takes a justification. These records are the raw material for GovRAMP's risk adjustments, operational requirements and false positives, and for the deviation request form. You still fill in GovRAMP's forms; Safeguard keeps the reasoning and dates.

9. Open fix pull requests (autonomous remediation, GA). AI Remediate on the Vulnerabilities page has Griffin AI generate remediation plans for you to review, then create pull requests that move dependencies to fixed versions. View Fix shows upgrade options with breaking change warnings. Autonomous remediation ships switched off, with every category set to Manual, so a person approves each change unless you decide otherwise. The merged pull request and the release that ships it are your SI-2 closure evidence for the POA&M row.

10. Export the month's data (bulk data export, GA). Tables can be filtered, sorted and exported in formats including CSV, Excel, JSON and PDF, and SBOMs export as SPDX or CycloneDX. The policies docs list compliance reporting by policy, exception history and violation trends. Each month, export open and closed component findings, map them into GovRAMP's POA&M template and inventory workbook, and roll the same export up by CVSS band for TX-RAMP. Then write the component section of the executive summary yourself: unique vulnerabilities opened, closed and open, KEV-listed and past-due counts, your deduplication rule, and active exceptions.

Requirement, what Safeguard does, what you still own

Evidence that still comes from other tools and people

Infrastructure, database, web application and compliance scans. GovRAMP requires these monthly, authenticated and across the full boundary. They come from your infrastructure and configuration scanning tools.

The 3PAO. Initial scans, the readiness or security assessment report, the annual assessment of a third of the controls and penetration tests come from your accredited 3PAO. The PMO assesses GovRAMP Core, and DIR assesses TX-RAMP.

Incident reporting. GovRAMP has its own incident communications procedures. TX-RAMP requires notice of a breach within 48 hours, plus any reporting the law requires, including to the Texas Attorney General when 250 or more Texans are affected.

Annual plans and process. The configuration management, contingency, supply chain risk management and monitoring plans, and the incident response test, are your documents. For the development process behind the evidence, see our sibling post on proving secure software development to a federal contracting officer.

What Safeguard does not do

• It does not give you, or hold, any GovRAMP, TX-RAMP or FedRAMP status. Safeguard is not a 3PAO and cannot certify, assess or vouch for your product. On Safeguard's own posture: its docs say it does not hold a FedRAMP authorization; its architecture is designed for FedRAMP High, a design target rather than an authorization; and its SOC 2 Type II audit is in progress.
• It does not scan operating systems, networks, databases or configuration baselines. It covers software components in source, container images and SBOMs. GovRAMP's required OS, database, web application and compliance scans come from other tools.
• Its application testing engines are not part of this flow. SAST and DAST are generally available. Do not present them as the web application scans GovRAMP requires.
• It does not write or file your POA&M, executive summary or SPECTRIM report. It supplies the component data and exception records. The plan of action, its milestones and the narrative are yours.
• It has no TX-RAMP page, and its StateRAMP page uses the old name. The six scan requirements check what your inventory contains. They do not model GovRAMP's 30, 90 and 180 day windows or deficiency triggers; track those yourself.
• It does not deploy fixes. It can open the pull request that fixes your dependency. Testing, release and production deployment stay with you.
• Gates are platform-side. A local safeguard scan writes results but does not fail a build, and policy outcomes are switched on per workspace.
• Some features are not at full depth. The continuous scanning API is not yet available, and fork and patch is generally available.

Common mistakes

• Sending only infrastructure scans. The package passes format checks while application libraries go unreported, until an agency asks about a widely reported library flaw.
• Inventory rows that cannot be matched. Use the same names for images and services in your inventory workbook, your scanners and Safeguard.
• Starting the clock at the monthly scan. The finding exists from the day the advisory applies to a component you ship. Noticing it at month end uses up part of your 30 days.
• Counting the same CVE fifty times. One library in one base image appears on every host built from it. Deduplicate and explain your method, or your unique count trips the 20% trigger with no real change in risk.
• Treating KEV as optional. The program text may not mention it, but a data call or an agency contract will.
• Quoting the old name or the old manual. Use GovRAMP and TX-RAMP Manual 4.0, and note the former name once.
• Assuming Texas reciprocity is automatic. Since 30 October 2024 you must request it, and report GovRAMP status changes.
• Open-ended risk acceptances. Every deviation needs a rationale and a review date.
• Claiming a status you do not hold. Name the status, impact level and date, or say you are in process.

FAQ

Is GovRAMP the same as StateRAMP?

Yes. GovRAMP's Security Assessment Framework calls the organization StateRAMP dba GovRAMP, and its September 2025 revision reflects the new name. Statuses, the NIST basis and monitoring carried over.

How often does GovRAMP require vulnerability scanning?

At least monthly for Ready, Provisionally Authorized and Authorized products, with results sent to the GovRAMP PMO. Core reports quarterly.

What are the GovRAMP remediation timelines for vulnerabilities?

High-risk within 30 days, moderate within 90 and low within 180, unless a control sets a shorter period, per the Continuous Monitoring Guide 2.0. Late items count toward escalation triggers.

How often does TX-RAMP require vulnerability reports?

Quarterly for Level 2 and annually for Level 1, through SPECTRIM, with counts per CVSS band and plans for high and critical items. Reciprocal certifications report through GovRAMP or FedRAMP instead.

Does a GovRAMP status count for TX-RAMP?

Yes, on request. Manual 4.0 grants TX-RAMP Level 2 to GovRAMP Core, Ready, Provisionally Authorized and Authorized services. A Snapshot earns only provisional certification.

Do GovRAMP or TX-RAMP require an SBOM?

Neither program's documents reviewed here require an SBOM by that name. Both require an accurate component inventory under CM-8, and GovRAMP requires a monthly inventory workbook that scans must match. An SBOM per release is the most practical way to produce the software part of that inventory, and some state contracts ask for one directly.

Do GovRAMP or TX-RAMP require patching CISA KEV vulnerabilities by a deadline?

Not in their published documents as of October 2026. GovRAMP can issue an out-of-cycle data call with accelerated timelines based on CISA guidance, and FedRAMP now ties KEV remediation to BOD 26-04. Agency contracts may add a KEV clause. Treat KEV-listed, reachable components as first priority regardless.

Does TX-RAMP require a 3PAO?

No. DIR assesses submissions itself, and Fast Track accepts approved third-party reports. GovRAMP Ready and above do require a 3PAO.

Who runs TX-RAMP now?

DIR, for now. House Bill 150 (2025) created the Texas Cyber Command and transfers DIR's cybersecurity duties, including TX-RAMP, to it. Manual 4.0 says DIR continues to run the program until a memorandum between the two bodies says all duties have moved.

Getting the next monitoring cycle ready

Pick one service, map its images and repositories to Safeguard projects, and run a month of component findings next to your infrastructure scans. Compare the two lists, decide your deduplication rule, and add a component section to the next executive summary and POA&M before the PMO or an agency asks for it. You can download the Safeguard apps and CLI at https://safeguard.sh/download and read the full documentation at https://docs.safeguard.sh/docs .

The component findings on your POA&M close only when a fixed version ships, and the hardest rows are the ones where no fixed version exists yet. The block below sets out the routes Safeguard offers for both cases, including fork and patch.

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 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 GovRAMP provider, that is one POA&M row moving from open to fixed, with a tested change a person approved.

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

The second demo is a real session in the Safeguard desktop app. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with a dependency upgrade done and tests passing. The same flow works for clearing a high-risk component finding before its 30 days run out, with each step approved and recorded.

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

Quick check

Sources

• GovRAMP: Security Assessment Framework, version 4.2, adopted April 2026 (PDF)
• GovRAMP: Continuous Monitoring Guide and Escalation Process, version 2.0, June 2026 (PDF)
• GovRAMP: Vulnerability Scan Requirements Guide, version 1.2, March 2026 (PDF)
• GovRAMP: Document library
• Texas DIR: TX-RAMP Program Manual, version 4.0, effective 12 February 2026 (PDF)
• Texas DIR: Texas Risk and Authorization Management Program (TX-RAMP)
• Texas DIR: TX-RAMP Frequently Asked Questions
• NIST: SP 800-53 Rev. 5 catalog, OSCAL release 5.2.0 (JSON)
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: Known Exploited Vulnerabilities Catalog
• FedRAMP: NTC-0014, FedRAMP Response to CISA BOD 26-04
• Safeguard Docs: StateRAMP framework
• Safeguard Docs: Compliance
• Safeguard Docs: Generate SBOM
• Safeguard Docs: Continuous Scanning
• Safeguard Docs: Vulnerabilities
• Safeguard Docs: Policies and Gates
• Safeguard Docs: CLI Usage

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