9line tells agencies which vulnerabilities in their software and AI supply chain actually affect them, with evidence an assessor can re-check. A customer submits a repository or container image through the web application or API. 9line generates a CycloneDX SBOM, inventories the AI models and agents it contains, matches components against vulnerability data, and determines whether each vulnerable code path is reachable using a deterministic call-graph engine. It returns a VEX document in which every statement carries its evidence. An in-boundary model (Amazon Bedrock in AWS GovCloud) explains verdicts but cannot clear a finding.
FedRAMP 20x defines 46 Key Security Indicators in ten themes. Class C requires each to be persistently validated by at least two automated methods, with 30 days of daily results. Select an indicator for FedRAMP's statement, the controls it maps to, and how it is validated.
The effectiveness of relevant cybersecurity education and training is persistently reviewed, including at least general training for all employees, role-specific training for employees in high risk roles, training for development and engineering staff on secure software delivery, and training for staff involved with incident response or disaster recovery.
Modifications to the cloud service offering are logged and monitored.
Changes to machine-based information resources are executed through the redeployment of version controlled resources rather than direct modification wherever reasonable.
The effectiveness of documented change management procedures is persistently reviewed.
Persistent testing and validation of changes throughout deployment is automated.
The functionality and privileges for infrastructure and services are strictly defined.
Automated services are used to persistently assess the security of all machine-based information resources and automatically enforce their intended operational state.
The use and configuration of third-party machine-based information resources is persistently compared against the original provider's best practices and guidance.
Machine-based information resources are persistently reviewed to ensure they have a minimal attack surface and that lateral movement is minimized if compromised.
Machine-based information resources are persistently reviewed to ensure they are appropriately optimized for high availability and rapid recovery.
Machine-based information resources are persistently reviewed to ensure they are appropriately configured to limit inbound and outbound network traffic.
The effectiveness of protection against denial of service attacks and other unwanted activity for machine-based information resources is persistently reviewed.
Logical networking and related capabilities are used and persistently reviewed to enforce traffic flow controls.
The lifecycle and privileges of all accounts, roles, and groups are securely managed using automation.
Secure passwordless methods are used for user authentication and authorization when feasible, otherwise strong passwords with phishing-resistant MFA is used.
Identity and access management measures are used and persistently reviewed to ensure each user or device can only access the resources they need.
A least-privileged, role and attribute-based, and just-in-time security authorization model is used and persistently reviewed for all user and non-user accounts and services.
Appropriately secure authentication methods are used and persistently reviewed for non-user accounts and services.
Accounts with privileged access are disabled or otherwise secured in response to suspicious activity.
Incident after action reports are generated and lessons learned are persistently incorporated.
The effectiveness of documented incident response procedures is persistently reviewed.
Past incidents are persistently reviewed for patterns or vulnerabilities that were not previously apparent or identified.
A least-privileged, role and attribute-based, and just-in-time access authorization model is used and persistently reviewed for access to log data based on organizationally defined data sensitivity.
The configuration of machine-based information resources, especially infrastructure as code, is persistently evaluated and tested.
A list of information resources and event types that will be logged, monitored, and audited is maintained and persistently reviewed to ensure these activities occur.
A Security Information and Event Management (SIEM) or similar system(s) is used and persistently reviewed for centralized, tamper-resistant logging of events, activities, and changes.
Logs are persistently reviewed and audited.
Authoritative sources are used to automatically generate real-time inventories of all information resources when needed.
Executive support for achieving the provider's security goals is persistently reviewed and demonstrated.
The effectiveness of the provider's investments in achieving security goals is persistently reviewed.
The effectiveness of building security and privacy considerations into the Software Development Lifecycle and aligning with CISA Secure By Design principles is persistently reviewed.
The effectiveness of the provider's vulnerability disclosure program is persistently reviewed.
The alignment of machine-based information resource backups with defined recovery objectives is persistently reviewed.
The alignment of recovery plans with defined recovery objectives is persistently reviewed.
The desired Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) are defined and persistently reviewed for alignment with the provider's business needs and capabilities.
The capability to recover from incidents and contingencies aligned with defined recovery objectives is persistently tested.
Persistently identify, review, and mitigate potential supply chain risks.
Third party software information resources are automatically monitored for upstream vulnerabilities using mechanisms that may include contractual notification requirements or active monitoring services.
The configuration of machine-based information resources is managed using automation and persistently reviewed for drift.
Management, protection, and regular rotation of digital keys, certificates, and other secrets is automated and persistently reviewed.
Information resources are persistently evaluated for opportunities to improve security and those improvements are persistently made.
Plans, procedures, and the state of information resources are persistently reviewed after making changes to limit and remove unwanted residual elements that would likely negatively affect the confidentiality, integrity, or availability of federal customer data.
Unwanted federal customer data is removed promptly when requested by an agency in alignment with customer agreements, including from backups if appropriate; this typically applies when a customer spills information or when a customer seeks to remove information from a service due to a change in usage.
Information is encrypted or otherwise secured from unwanted access or modification.
The authenticity and integrity of communications between machine-based information resources is persistently validated using automation.
Use cryptographic methods to validate the integrity of machine-based information resources.
Statements: FedRAMP Consolidated Rules 2026.10.13.01 (github.com/FedRAMP/rules). Status: 9line Security Decision Record, updated 2026-10-21.
FedRAMP 20x sets 36 rules for how a provider detects vulnerabilities and responds (VDR) and how it evaluates and reports them (VER). They are required for new 20x applications from 2026-12-07, with grace to 2027-03-07. Each entry below is FedRAMP's rule as it applies at Class C, with the status of 9line's own boundary against it. 9line implements these same rules for the customers it runs inside; the status here is Optimal's hosted service, which is being deployed.
Providers SHOULD use automated services to improve and streamline vulnerability detection and response.
Providers SHOULD NOT deploy or otherwise activate new machine-based information resources with Known Exploited Vulnerabilities.
Providers SHOULD automatically perform vulnerability detection on representative samples of new or significantly changed information resources.
Providers MUST systematically, persistently, and promptly discover and identify vulnerabilities within their cloud service offering using appropriate techniques such as assessment, scanning, threat intelligence, vulnerability disclosure mechanisms, bug bounties, penetration testing, incident response, automated control testing, supply chain monitoring, and other relevant capabilities; this process is called vulnerability detection. Vulnerability detection includes persistently verifying and validating that information resources and processes are operating as intended and documented for FedRAMP Practices.
Providers SHOULD make design and architecture decisions for their cloud service offering that mitigate the risk of vulnerabilities by default AND decrease the risk and complexity of vulnerability detection and response.
Providers MUST treat problems or failures with their vulnerability detection and response processes as vulnerabilities.
Providers SHOULD NOT weaken the security of information resources to facilitate vulnerability scanning, detection, or assessment activities.
Providers MUST systematically, persistently, and promptly track, evaluate, monitor, mitigate, remediate, assess exploitation of, report, and otherwise manage all detected vulnerabilities within their cloud service offering; this process is called vulnerability response.
Providers MAY sample effectively identical information resources, especially machine-based information resources, when performing vulnerability detection UNLESS doing so would decrease the efficiency or effectiveness of vulnerability detection.
Providers SHOULD remediate Known Exploited Vulnerabilities according to the due dates in the CISA Known Exploited Vulnerabilities Catalog (even if the vulnerability has been fully mitigated) as required by CISA Binding Operational Directive (BOD) 26-04 or any successor guidance from CISA.
Providers of FedRAMP 20x Class C offerings MUST verify and validate the status of machine-based information resources at least once every 3 days.
Providers MUST verify and validate the status of non-machine-based information resources at least once every 3 months.
Providers with Class C Certifications SHOULD persistently perform vulnerability detection on all information resources that are NOT likely to drift, at least once every month.
Providers with Class C Certifications SHOULD persistently perform vulnerability detection on all information resources that are likely to drift, at least once every 14 days.
Providers with Class C Certifications SHOULD persistently perform vulnerability detection on representative samples of similar machine-based information resources, at least once every 3 days.
Providers with Class C Certifications SHOULD partially mitigate vulnerabilities, fully mitigate vulnerabilities, or remediate vulnerabilities to a lower Potential Agency Impact N-rating within the timeframes from evaluation shown below, factoring for the current Potential Agency Impact N-rating as defined in VER-EVA-EPA (Estimate Potential Agency Impact), internet reachability, and likely exploitability:
Providers SHOULD mitigate or remediate remaining vulnerabilities during routine operations as determined necessary by the provider.
Providers MUST assume the exploitation of vulnerabilities can be automated UNLESS they have evidence proving otherwise.
Providers SHOULD consider at least the following factors when considering the context of the cloud service offering to evaluate detected vulnerabilities:
Providers SHOULD evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are false positive vulnerabilities.
Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are internet-reachable vulnerabilities.
Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are likely exploitable vulnerabilities.
Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to estimate the likely potential agency impact of exploitation on government customers AND assign one of the following Potential Agency Impact N-ratings (PAIN):
Providers SHOULD evaluate detected vulnerabilities, considering the context of the cloud service offering, to identify logical groupings of affected information resources that may improve the efficiency and effectiveness of vulnerability response by consolidating further activity; FedRAMP Vulnerability Detection and Response rules are then applied to these consolidated groupings of vulnerabilities instead of each individual detected instance.
Providers MUST include the following information on accepted vulnerabilities when reporting on vulnerability detection and response activity:
Providers SHOULD include high-level overviews of ALL vulnerability detection and response activities conducted during this period for the cloud service offering; this includes vulnerability disclosure programs, bug bounty programs, penetration testing, assessments, etc.
Providers MUST NOT irresponsibly disclose specific sensitive information about vulnerabilities that would likely lead to exploitation, but MUST disclose sufficient information for informed risk-based decision-making to all necessary parties.
Providers MUST report vulnerability detection and response activity (including persistent verification and validation) to all necessary parties persistently, summarizing ALL activity since the previous report; these reports are FedRAMP Certification Data and are subject to FedRAMP Certification Data Sharing rules.
Providers MAY responsibly disclose vulnerabilities publicly or with other parties if the provider determines doing so will NOT likely lead to exploitation.
Providers MUST include the following information (if applicable) on detected vulnerabilities when reporting on vulnerability detection and response activity, UNLESS it is an accepted vulnerability:
Providers with Class C Certifications SHOULD evaluate ALL vulnerabilities as required by VER-EVA (Evaluation) within 5 days of detection.
Providers with Class C Certifications SHOULD treat internet-reachable likely exploitable vulnerabilities where Potential Agency Impact N-rating > 3 as a FedRAMP Reportable Incident until they are partially mitigated vulnerabilities at N3 or below.
Providers MUST categorize any vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation as an accepted vulnerability.
Providers MUST report vulnerability detection and response activity to all necessary parties in a consistent format that is human readable at least monthly.
Providers with Class C Certifications SHOULD make all recent historical vulnerability detection and response activity available in JSON format for automated retrieval by all necessary parties (e.g. using an API service or similar); this information SHOULD be updated persistently, at least once every 14 days.
Providers with Class C Certifications MAY treat likely exploitable vulnerabilities that are NOT internet-reachable where Potential Agency Impact N-rating = 5 as a FedRAMP Reportable Incident until they are partially mitigated vulnerabilities at N4 or below.
Rule text: FedRAMP Consolidated Rules 2026.10.13.01. Status: 9line Security Decision Record.
Every vulnerability 9line detects, whatever it lives in, is evaluated the same way: is it internet-reachable, is it likely exploitable, and what is its Potential Agency Impact, the N0 to N5 rating FedRAMP uses to set remediation timeframes (VER-EVA-EPA). This table counts the open ones by the type of information resource and by rating. Counts only; the vulnerabilities themselves are in the certification package.
Not running yet. Published once 9line is scanning inside the boundary: open vulnerabilities by information resource type and Potential Agency Impact rating, counts only.
FedRAMP 20x Class C certification of 9line on the Program path. 2 of 9 milestones complete. Updated at least quarterly.
Release and vulnerability-database signing key in KMS, signing roles limited to the release workflow, signing log in CloudTrail.
Completed 2026-10-15
Certification Package Overview published in FedRAMP's JSON schema and the listing request submitted (FRC-APP-MLF, MKT-CSO-PML); received by the FedRAMP Intake Team.
Completed 2026-10-16
After FedRAMP's JSON schema validation and human review of the listing request.
Target date to be published
Audit logging into immutable storage, AWS Config with the FedRAMP Moderate conformance pack, Security Hub, GuardDuty, Inspector, and automated daily validation of all 46 Key Security Indicators.
Target date to be published
The service behind WAF in a network with an egress allowlist, sign-in with MFA, DNSSEC-signed domain, model inference on Amazon Bedrock.
Target date to be published
Repository on GitHub Enterprise Cloud with required review and required checks on every change.
Target date to be published
The daily metrics and summaries the Security Decision Record carries (SDR-CSX-KMT).
Target date to be published
A FedRAMP Recognized assessor with no advisory role in the prior two years (REC-IAS-SEP).
Target date to be published
Certification package (CPO and SDR) and assessment submitted to FedRAMP.
Target date to be published
The FedRAMP certification package (the Certification Package Overview, the Security Decision Record with daily Key Security Indicator data, and vulnerability detection and response reports) is available to federal agencies, the FedRAMP PMO and our independent assessor. Access requires an account with multi-factor authentication; every access is logged.
To request access, email support@gooptimal.io from your government address with your agency and role.
Everything on this page, as published files. The JSON and Markdown are generated together from one source.
| Document | Rule | JSON | Markdown |
|---|---|---|---|
| Certification Package Overview | FRC-CSO-PKG | cpo.json | — |
| Public information | CDS-CSO-PUB | public-information.json | public-information.md |
| Key Security Indicator status | KSI | ksi-status.json | ksi-status.md |
| Progress toward certification | MKT-IIP-DCP | progress.json | progress.md |
| Vulnerability rules (VDR and VER) status | VDR, VER | vdr-ver-status.json | vdr-ver-status.md |
| Open vulnerabilities by resource and rating | VER-EVA-EPA | vulnerability-summary.json | vulnerability-summary.md |
