Skip to main content
RSASecurity & Compliance

Solution Spotlight – Security Insights Broker

Overview

Security and compliance leaders face a materially different threat environment than they did five years ago. The proliferation of large language models and agentic AI systems has led us to the “post-mythos era.” This has lowered the barrier for adversaries to discover vulnerabilities, craft exploits, and automate attacks at a pace that outstrips traditional security program cadences and capabilities. Financial services organizations are contending with an attack surface (both cloud and on-premises) that grows faster than their security teams can evaluate it, and the consequences are already appearing in regulatory exposure, breach liability, and audit findings. 

Most organizations respond to this pressure the way they always have, by limited to scheduling annual or semi-annual penetration tests with a third-party firm, running periodic vulnerability scans, and relying on security engineers to manually triage a growing backlog of findings. However, these approaches were built for a slower threat environment. Point-in-time assessments are stale the moment they are delivered. Manual triage stretches remediation timelines from days to months. Siloed tools produce fragmented findings with no unified prioritization signal, leaving security programs perpetually reactive. 

In this solution, we present a better way to address the problems outlined above. Security Insights Broker is Vertical Relevance’s consulting accelerator built on AWS Security Agent, Amazon’s managed service for autonomous penetration testing and code review. It provides a single, deployable infrastructure package that continuously probes cloud-hosted and internet-accessible on-premises targets, reviews source code for vulnerabilities, enriches findings with contextual data from across the AWS security ecosystem, and surfaces prioritized results directly into Security Hub through a REST API and automated orchestration pipeline. It is designed to be deployed once per client engagement and customized to match the client’s existing architecture. 

By combining autonomous execution with enrichment data from Amazon Inspector2, AWS Config, and Security Hub, Security Insights Broker delivers findings with a prioritization signal that reflects actual environmental risk rather than theoretical severity scores. Security teams spend less time triaging noise and more time remediating confirmed, high-impact issues. For clients on AWS, the solution integrates with services they already operate. For clients with multi-cloud or on-premises infrastructure, DNS-based domain verification extends pentest coverage beyond the cloud boundary. 

Prescriptive Guidance 

Before diving into Security Insights Broker, it is important to acknowledge that AWS Security Agent is a new and rapidly evolving managed service, and this solution is designed to grow with it. The guidance here reflects the current state of the service and our deployment patterns as of the time of writing, but VR will continue to adapt module configurations and API integrations to best serve financial services organizations by staying on the leading edge of security innovation. 

Definitions

  • Post-Mythos Era — The current period in cybersecurity characterized by the widespread availability of AI and large language model (LLM) capabilities to adversaries. Threat actors can now leverage powerful, widely available LLM’s (e.g. Anthropics’s Mythos) to automate vulnerability discovery, generate exploit code, and scale attacks in ways that were previously cost-prohibitive. 
  • AWS Security Agent — A managed AWS service that performs autonomous penetration testing against internet-accessible targets and automated code review against connected source repositories. It is the core service that Security Insights Broker wraps and orchestrates.
  • Agent Space — An isolated workspace within AWS Security Agent service that scopes all pentest and code review activity for a given client or deployment. All configurations, jobs, and findings belong to an Agent Space. Security Insights Broker provisions one Agent Space per client environment. 
  • Pentest Configuration — A reusable definition of one or more targets (domains or endpoint URIs) that AWS Security Agent should probe. A Pentest Configuration is created once and can be used to start multiple Pentest Jobs over time. Domain-based targets require DNS verification before scanning can begin. 
  • Pentest Job — A single execution of a Pentest Configuration. Each job produces a set of findings scoped to that run. Jobs progress through RUNNING and COMPLETED (or FAILED) states, which Security Insights Broker polls via Step Functions. 
  • Code Review Configuration — A reusable definition of one or more connected source repositories that AWS Security Agent will analyze for vulnerabilities. Like a Pentest Configuration, it is created once and used to start multiple Code Review Jobs. 
  • Code Review Job — A single execution of a Code Review Configuration against the configured repositories. Produces findings categorized by vulnerability type and severity. 
  • Firm Context — A set of markdown documents that describe a client’s environment to AWS Security Agent, including network topology, IAM strategy, infrastructure conventions, and system architecture. Firm context is stored in S3 and read by the service during analysis to reduce false positives and improve finding accuracy. 
  • Finding — A discrete security issue identified by AWS Security Agent during a pentest or code review job. Findings carry metadata including risk level (CRITICAL, HIGH, MEDIUM, LOW, INFORMATIONAL), risk type (e.g., INJECTION, BROKEN_ACCESS_CONTROL), confidence level, and status. 
  • Enrichment — The process by which Security Insights Broker augments raw pentest findings with correlated data from Amazon Inspector2, AWS Config, and AWS Security Hub. Enrichment produces a composite risk score per finding that reflects actual environmental exposure, not just the finding’s inherent severity. 
  • AWS Security Finding Format (ASFF) — The standardized JSON schema that AWS Security Hub uses to ingest and display findings from integrated services. Security Insights Broker converts Security Agent findings into ASFF before pushing them to Security Hub, enabling clients to manage them alongside findings from other security tools. 
  • Step Functions State Machine — The AWS orchestration service used by Security Insights Broker to coordinate the full job lifecycle: starting a job, polling for completion, retrieving findings, running enrichment, and pushing results to Security Hub. The state machine handles retries, error handling, and sequencing automatically. 

Best Practices / Design Principles  

In this section, we cover the best practices implemented in the Security Insights Broker solution. This section introduces conceptual ideas related to autonomous security testing and finding management so that the later sections can focus on the technical implementation of each. 

Establish firm context before scanning 
AWS Security Agent analyzes targets with the context it has available. Without firm context, the service lacks knowledge of intentional architectural patterns, approved IAM trust relationships, known-public endpoints, and infrastructure conventions specific to the client. Without firm context, you get a higher volume of findings that require manual validation before they can be acted on. 

VR recommends treating firm context population as a pre-deployment requirement. The four context document categories (network topology, IAM strategy, IaC conventions, and system architecture) should be filled in as accurately as possible for the target environment before the first scan runs. In fact, a partial but accurate context document is more valuable than a complete but generic one. 

Define and verify target scope explicitly 
Penetration testing against targets that are not explicitly approved by the team that owns them has not authorized is a legal and reputational risk. Scanning targets that are shared with other tenants or business units without proper authorization can cause financially and reputationally costly incidents. 

We recommend producing a formal scope document and obtaining written approval from all BU’s and teams that could be potentially impacted prior to creating any pentests. This document should enumerate every domain and endpoint URI that is in bounds, confirm team ownership and authorization for each, and note any targets that should be explicitly excluded. 

Prefer continuous testing cadence over point-in-time assessments 
A penetration test conducted once a year reflects the state of the environment on one day. Code is deployed continuously, infrastructure changes frequently, and new vulnerabilities are disclosed on timescales of days. A point-in-time assessment cannot provide meaningful ongoing assurance in that environment. 

VR recommends configuring pentest and code review jobs to run on a recurring schedule rather than treating them as one-off executions. The Step Functions state machine in this solution is designed to be invoked repeatedly against the same configurations. Organizations should establish a testing cadence that matches their deployment frequency. For instance, teams that deploy weekly should run code review jobs at least weekly, while teams with frequently changing external infrastructure should run pentest jobs on a similar interval. 

Use enrichment to prioritize findings, not just severity scores 
Raw findings from a security scanner carry an inherent severity rating, but severity alone is a poor basis for remediation prioritization. A CRITICAL finding against an API endpoint that has no associated Lambda vulnerabilities, no Config violations, and no existing Security Hub findings represents a different level of actual risk than the same severity finding against an endpoint that is already flagged across multiple services. 

We advise our clients to treat enriched findings as the primary input to their remediation backlog rather than raw finding lists. The enrichment pipeline in Security Insights Broker correlates pentest findings with data from Amazon Inspector2, AWS Config, and Security Hub to produce a composite risk score that reflects environmental exposure. Teams that work from enriched, scored findings will direct remediation effort more accurately than teams working from unenriched severity ratings alone. 

Centralize findings in Security Hub as the operational record 
Security teams working across multiple tools, accounts, and services spend significant time aggregating findings before they can act on them. Without a centralized findings store, it is difficult to track remediation status, assign ownership, or measure program effectiveness over time. 

VR recommends configuring AWS Security Hub as the authoritative record for all findings produced by this solution. Security Insights Broker pushes findings to Security Hub in ASFF format automatically at the conclusion of each job. Clients who already use Security Hub for findings from GuardDuty, Inspector2, or other services benefit immediately from having pentest and code review results in the same interface. Clients who are new to Security Hub should treat this deployment as the prompt to enable it and establish a triage workflow. 

Security Insights Broker 

Security Insights Broker is built as a modular, deployable wrapper around AWS Security Agent that provides the orchestration, API surface, enrichment pipeline, and firm-context management that the core service does not offer out of the box. This section covers the complete architecture of the solution, from the Terraform modules that provision the underlying AWS infrastructure to the Lambda functions and Step Functions state machine that drive job execution and finding management. Understanding this architecture is important because each component can be configured independently to fit alongside organizations’ existing capabilities – knowing how the pieces fit together makes that customization straightforward rather than opaque. The solution demonstrates how an orchestration layer combined with AWS Security Agent’s autonomous capabilities can produce a security testing program that is repeatable, auditable, and integrated with the broader AWS security ecosystem. 

Components

  • AWS Security Agent — The core managed service that executes autonomous penetration tests against verified target domains and endpoint URIs and performs automated code reviews against connected source repositories.  
  • Amazon API Gateway — Exposes the Security Insights Broker REST API as a managed HTTP endpoint with IAM SigV4 authentication enforced at the resource level. All ten routes covering pentest configuration, code review configuration, job management, findings retrieval, and remediation triggering are defined as API Gateway resources backed by a single Lambda integration 
  • AWS Lambda — Implements two distinct functions: the API handler that processes inbound REST requests and translates them into Security Agent API calls, and the Step Functions task handler that executes each state in the job orchestration pipeline. Both functions run on Python 3.12 and retrieve configuration from SSM Parameter Store at runtime rather than relying on hardcoded environment values 
    • boto3 Lambda Layer — A pre-packaged Lambda layer shipping boto3 >= 1.43 that must be attached to both Lambda functions. The standard Lambda runtime boto3 does not include the Security Agent client; this layer bridges that gap and must be updated as the service API evolves 
  • AWS Step Functions — Orchestrates the end-to-end job lifecycle through a STANDARD state machine that sequences job startup, status polling, finding retrieval, enrichment, and Security Hub ingestion.  
  • Amazon S3 — Hosts the firm context documents that Security Agent reads during analysis to reduce false positives. The context bucket is encrypted with a customer-managed KMS key, blocks all public access, and enforces TLS-only access through a bucket policy. Terraform uploads all markdown files from the context/ directory on each apply 
  • AWS Systems Manager Parameter Store — Stores sensitive configuration values including the Agent Space ID, scan service role ARN, context bucket name, and CloudWatch log group name as SecureString parameters encrypted with the customer-managed KMS key.  
  • AWS Key Management Service (KMS) — Provides a customer-managed encryption key used across Lambda logs, S3, SSM parameters, and CloudWatch log groups. A single CMK with rotation enabled serves the full stack, with key policy grants scoped to specific roles rather than broad IAM policies 
  • AWS Security Hub — Receives enriched findings at the conclusion of each Step Functions execution in ASFF format. Security Hub serves as the operational record for all pentest and code review findings, enabling the client’s security operations team to triage, assign, and track remediation alongside findings from other integrated services 
    • ASFF (AWS Security Finding Format) — The standardized finding schema required by Security Hub. Security Insights Broker converts raw Security Agent findings into ASFF at the PushToSecurityHub state 
  • Amazon Inspector2 — Queried during the enrichment phase to retrieve existing vulnerability findings against Lambda functions associated with pentest target endpoints. Inspector2 finding counts by severity contribute to the composite risk score assigned to each enriched finding 
  • AWS Config — Queried during enrichment to identify compliance violations against API Gateway resources associated with pentest targets. Non-compliant resource findings from Config contribute to the composite risk score alongside Inspector2 and Security Hub data 
  • Amazon VPC — Provides network isolation for the pentest runner through a dedicated VPC with a NAT Gateway that gives the runner a stable egress IP 

How it works

Security Insights Broker operates through two parallel entry paths: (1) a REST API for direct programmatic control and (2) a Step Functions state machine for automated end-to-end job execution. These two entry paths are unified by AWS Security Agent as the core scanning service and backed by a shared foundation of encryption, configuration, and observability services. The following flow describes how a security job moves from initial configuration through scan execution, finding enrichment, and Security Hub ingestion. 

Figure-01

Architecture flow

  1. Foundation — The shared infrastructure layer that all other components depend on. KMS CMK provides encryption at rest for SSM parameters, S3 objects, Lambda logs, and CloudWatch log groups. SSM Parameter Store holds sensitive configuration values retrieved at Lambda runtime. The S3 context bucket stores firm context documents that Security Agent reads during analysis. CloudWatch Logs captures execution logs from both Lambda functions, the API Gateway access log, and Step Functions executions. The boto3 Lambda Layer provides the Security Agent client to both Lambda functions. IAM roles enforce least-privilege access boundaries between the Lambda execution context, the scan service, and Step Functions.
  2. REST API — The entry point for all programmatic interaction with Security Insights Broker. API Gateway receives authenticated requests (IAM SigV4) across ten routes covering pentest configuration, code review configuration, job management, findings retrieval, and remediation triggering. The api_handler Lambda processes each request, retrieves runtime configuration from SSM Parameter Store, and translates the request into the appropriate AWS Security Agent API call. Clients interact with this layer to create configurations, monitor job status, and retrieve findings on demand.
  3. Orchestration — The automated job lifecycle layer. The Step Functions Scan Orchestrator state machine drives jobs from start to completion without manual intervention, invoking sfn_handler Lambda at each state to execute a discrete action: starting the job, polling for completion, retrieving findings, running enrichment, and pushing results to Security Hub. The state machine manages retry logic with exponential backoff and graceful error handling so that transient failures do not terminate the pipeline.
  4. AWS Security Agent — The managed AWS service that performs all scanning activity within a scoped Agent Space. The Agent Space holds pentest configurations (with verified target domains), code review configurations (with connected source repositories), running jobs, and the raw findings those jobs produce. Security Agent launches the pentest runner, streams execution logs to CloudWatch, and reads firm context documents from S3 to inform its analysis.
  5. Pentest VPC — The network layer that gives the pentest runner a stable, controlled egress path. For pentest jobs, Security Agent creates an Elastic Network Interface (ENI) in the private subnet to host the runner. Outbound traffic routes from the ENI through the NAT Gateway in the public subnet and out through the Internet Gateway to reach external or internal targets. The NAT Gateway provides a consistent source IP, which matters when client targets have IP-based allow lists or to distinguish scan traffic from production traffic in logs.
  6. Findings — The raw output produced by Security Agent upon job completion. Each finding carries a risk level (CRITICAL, HIGH, MEDIUM, LOW, INFORMATIONAL), a risk type classification (INJECTION, BROKEN_ACCESS_CONTROL, etc.), a confidence level, a status, and a plain-language summary. sfn_handler retrieves all findings with pagination and passes them to the enrichment stage as the input to composite scoring.
  7. Enrichment & SIEM — The correlation and output layer. sfn_handler queries Amazon Inspector2 for vulnerability counts against Lambda functions associated with the pentest target, queries AWS Config for compliance violations against the API Gateway resource, and queries Security Hub for existing active findings on the same resource. A composite risk score is calculated from the base severity weight plus multipliers for Inspector2 findings (CRITICAL×3, HIGH×2) and Config violations. Enriched findings are converted to ASFF format and pushed to Security Hub via batch_import_findings, where they appear alongside findings from GuardDuty, Inspector2, and other integrated services.

Blueprint

The repository that hosts the code that deploys the solution described above can be found here and consists of the following components. 

Terraform Starter Environment — A ready-to-deploy Terraform environment that provisions the complete Security Insights Broker stack in a client account. Covers the Agent Space, REST API, Step Functions state machine, IAM roles, KMS encryption, SSM configuration, S3 context bucket, and Pentest VPC through ten composable modules, each independently configurable to match the client’s existing architecture.

REST API — The Lambda-backed API Gateway facade that gives clients and automated systems programmatic control over the full AWS Security Agent lifecycle. Handles pentest configuration, code review configuration, job management, findings retrieval, and remediation triggering across ten authenticated routes.

Scan Orchestrator — The Step Functions state machine and Lambda handler that drive jobs from start to completion without manual intervention. Manages status polling, finding retrieval, enrichment correlation against Inspector2 and AWS Config, and ASFF ingestion into Security Hub.

Firm Context Templates — Four markdown templates covering network topology, IAM strategy, infrastructure conventions, and system architecture that gets populated with client-specific data before the first scan. Uploaded to S3 and read by AWS Security Agent to reduce false positives and improve finding accuracy.

Pre-built boto3 Layer — A Lambda layer shipping boto3 >= 1.43 for Python 3.12, required because the standard Lambda runtime does not include the AWS Security Agent client. Attached to both Lambda functions and updated as the service API evolves.

Benefits

  • Rapid Client Deployment — Modular Terraform architecture enables us to stand up the complete Security Insights Broker stack in client environments with a single apply. This allows us to focus our time on the bespoke elements of security scanning such as creating firm context documents, determining which workloads should be prioritized, and customizing recurring job triggers to fit the organization’s needs 
  • Continuous Security Coverage — Pentest and code review jobs can be triggered on a recurring schedule against the same configurations, replacing point-in-time assessments with ongoing coverage that reflects the current state of the environment rather than a snapshot from a fixed date 
  • Cloud and On-Premises Flexibility — DNS-based domain verification (DNS TXT record, HTTP route, and Private VPC methods) extends penetration testing coverage to any domain the client owns or has authorization to test, regardless of whether the target runs on AWS, another cloud provider, or on-premises infrastructure 
  • Enriched Finding Prioritization — Composite risk scoring correlates raw Security Agent findings with Inspector2 vulnerability counts, AWS Config compliance violations, and existing Security Hub findings to produce a prioritized output that reflects actual environmental exposure rather than theoretical severity alone 
  • Centralized Findings Management — All pentest and code review findings are pushed to Security Hub in ASFF format at the conclusion of each job. This gives security operations teams a single interface for findings from Security Insights Broker alongside GuardDuty, Inspector2, and other integrated services, especially when integrating Security Insights Broker with VR’s Security Dashboard Solution 
  • Automated Remediation Path — The /findings/{finding_id}/remediate API route triggers Security Agent’s code remediation capability directly from a finding, enabling teams to initiate fixes without leaving the Security Insights Broker interface or navigating the Security Agent console 

End Result

Security Insights Broker delivers a comprehensive security testing program built on AWS Security Agent that addresses the gap between what the managed service provides and what a financial services organization requires to secure its cloud workloads in the post-Mythos era. By deploying this solution, you get a robust, agentic-AI driven security testing capability that runs continuously, integrates natively with the AWS security ecosystem, extends to any verified domain regardless of where it is hosted, and scales with minimal ongoing maintenance.