Why BugBase is partnering with Stratus Cyber to help customers assess application, cloud, and internal risks, verify fixes, and maintain FedRAMP evidence.
FedRAMP, the Federal Risk and Authorization Management Program, standardizes security assessment for cloud services used by US federal agencies. A provider's responsibility continues after certification: it must maintain the required security activities and evidence. FedRAMP's provider responsibilities describe that ongoing work.
At BugBase, I want a pentest to help a team fix a weakness, verify the fix, and explain the result to the people relying on that service. That is the purpose behind our partnership with Stratus Cyber.
FedRAMP covers more than penetration testing. Access control, configuration, logging, incident response, and recovery are also part of the security program. FedRAMP Rev5 uses NIST security controls; FedRAMP 20x emphasizes automated validation through Key Security Indicators. The 20x overview explains the difference in approach.
The 2026 Consolidated Rules describe the assessment boundary through Minimum Assessment Scope: resources likely to handle federal customer data or affect its confidentiality, integrity, or availability. That gives teams a reason to examine cloud identities, private services, and administrative systems when those resources can affect the service.
These rules have phased effective dates. Providers should use the requirements and transition dates applicable to their certification path and class, as specified on each ruleset page.
Pentesting already belongs in this program. CA-8 addresses penetration testing, and the 2026 Vulnerability Detection and Response rules place it alongside other ways of detecting weaknesses. Our focus is making the resulting evidence useful for remediation and ongoing review.
Pentest Copilot is our penetration testing platform for application, cloud, and internal assessments. Teams configure scope, authentication, and assessment families to test the resources and access paths relevant to their service.
These assessment surfaces help investigate different questions:
| Assessment surface | Supported areas | Questions to investigate |
|---|---|---|
| Web applications and APIs | Authentication, authorization, and business logic | Can a user access another tenant's data or provider management functions? |
| Cloud environments | Workload identities, permissions, resource relationships, and supported configuration checks across AWS, Azure, and Google Cloud | Does an identity have access beyond what its workload needs? |
| Internal networks | Hosts, services, segmentation, privileged access, and Active Directory where present | What can an assumed compromised host or account reach? |
External Assessment supports authenticated and unauthenticated application testing. Internal Assessment examines network and identity relationships. Cloud assessment uses the Internal Assessment workflow, with discovery detecting provider scope from the identity attached to a cloud-hosted agent. Teams select the scope and assessment families, review findings, and run retests through the module workflow.
Consider a hypothetical reporting service with a web portal, cloud storage, and a private administration network. A useful assessment plan would examine tenant separation in the portal, the workload identity's access to stored reports, and access from the application network to administration systems. Each examines a different boundary around the same service.
These results give teams evidence of how least-privilege and boundary-protection measures behave in the scenarios tested. Teams can use the findings to correct weaknesses and retain the scope, observations, and retest results for independent assessment.
In the reporting example, excessive access to an empty test store and excessive access to agency records call for different impact evaluations. A technical finding needs that service context before a team can judge its consequences.
The 2026 Vulnerability Evaluation and Reporting rules separate three questions:
IRV and LEV are determinations; PAIN is the impact rating. Pentest evidence helps the provider connect reachability and exploitability to the agency data and workflows affected. In the reporting service, the access demonstrated during testing becomes part of the impact evaluation and the decision about what to fix.
Once a finding has been evaluated, someone has to own the fix and show whether it worked. This is where Stratus Cyber complements our testing. Its cloud security services and Stratus GRC-ITSM platform, which brings together compliance and IT service management, support the operational work around a finding.
In our reporting-service example, suppose testing identifies a workload identity with access to reports it should not read. Stratus's remediation workflow gives the team a place to associate the issue with the affected resource, assign the permissions change, and record the impact decision.
After the change, the team can use Pentest Copilot to retest that access. Keeping the finding, remediation decision, and retest evidence together helps the customer explain why it considers the issue resolved.
That explanation also matters at the next FedRAMP review. Stratus's continuous monitoring maintains the history of validation results, and its Trust Center makes monitoring reports and certification evidence available to authorized reviewers. Customers can use that history to show what was checked and which gaps still need attention.
Our partnership brings together Pentest Copilot's testing and retesting with Stratus's FedRAMP operations and reporting work. For customers, the combination supports assessment preparation, remediation verification, and evidence maintenance across the parts of their service being tested.
As a founder, I want the work done for FedRAMP to remain useful after the assessment. When permissions or network access change, the team should know what to retest, who owns a failure, and what evidence is needed to close it.
