Automating AWS Security Hub Prioritization with Amazon Bedrock and Claude Sonnet 4.6
Security Hub is great at collecting findings.
The harder part is what happens next.
Most cloud security teams do not struggle because findings are unavailable. They struggle because there are too many findings, not enough context, and limited time to decide what should be fixed first.
Every day, engineers and managers still need practical answers:
- Which findings need attention first?
- Which ones affect production?
- Which vulnerabilities have a fix available?
- Which ECR image findings are still relevant?
- Which issues are real risk, and which ones are noise?
- What should leadership see without reading hundreds of raw findings?
This post walks through a practical automation pattern for that problem.
The plan uses AWS Security Hub, AWS Lambda, Amazon Bedrock, Claude Sonnet 4.6, Amazon S3, Amazon ECR, and EventBridge to produce daily AI-assisted security reports.
The goal is not to let AI automatically fix security issues.
The goal is simpler and safer: reduce triage noise, apply consistent prioritization, and generate reports that both engineers and managers can actually use.
Why Security Hub Findings Need More Than Severity
Security Hub gives teams a central place to review security findings across AWS services and partner integrations. That is valuable.
But severity alone is not enough.
A CRITICAL finding may belong to an old ECR image that is no longer deployed or promoted. A MEDIUM finding may involve an internet-facing production resource, sensitive data, or an IAM exposure that deserves faster attention.
That is where many teams lose time.
They are not just asking, “Is this finding high severity?”
They are asking:
Does this finding matter in my environment, right now, and what should we do about it?
That is the operational gap this workflow is designed to close.
It gives the team a repeatable way to filter, score, summarize, and prioritize findings before they become another long spreadsheet or noisy dashboard.
For engineers, better prioritization reduces wasted effort and alert fatigue.
For managers, it creates clearer visibility into business impact, ownership, SLA, and remediation progress.
The Workflow at a Glance
The automation runs as a daily reporting pipeline.
EventBridge daily schedule
-> Lambda
-> AWS Security Hub findings
-> ECR latest image filtering
-> deterministic scoring
-> Amazon Bedrock Claude analysis
-> S3 JSON, HTML, and CSV reports
The default AWS Region in the package is:
ap-southeast-2
The configured default Bedrock inference profile is:
au.anthropic.claude-sonnet-4-6
The package also includes a model availability check script. That matters because Amazon Bedrock model access can depend on the AWS account, enabled model access, Region, and inference profile availability.
This is a small detail, but an important one. A good security automation should fail early during setup, not halfway through a scheduled production run.
What the Lambda Function Does
The Lambda function does several important things before anything is sent to Claude.
First, it collects active Security Hub findings using defined filters:
RecordState = ACTIVE
WorkflowStatus = NEW or NOTIFIED
SeverityLabel = CRITICAL, HIGH, or MEDIUM
UpdatedAt within the configured DAYS_BACK window
By default, the reporting window is:
DAYS_BACK=7
The maximum number of findings processed is controlled by:
MAX_FINDINGS=300
That limit is intentional.
The purpose of this workflow is not to analyze every historical finding in the account. The purpose is to produce a focused, useful, daily operational report.
Without that kind of scope control, AI-assisted reporting can quickly become just another noisy output.
Reducing ECR Vulnerability Noise
One of the most useful parts of this design is how it handles ECR container image findings.
Container vulnerability findings can become noisy when old images remain in scan history. In many environments, teams care most about the latest tagged image because that is usually the image most likely to be deployed, promoted, or reused.
The Lambda function checks ECR image details and compares the finding’s image digest against the latest pushed tagged image digest in the repository.
If the ECR finding does not belong to the latest tagged image, it is excluded from the AI analysis.
That sounds simple, but it is operationally important.
It keeps the report focused on findings that are more likely to matter today, instead of flooding the team with stale vulnerabilities from old images.
This is also the right way to use AI in a security workflow. Do not send messy, low-quality input to a model and hope the model sorts it out. Apply deterministic AWS-side logic first. Then send the model a cleaner, narrower, better-structured problem.
Deterministic Scoring Comes Before AI
The plan does not rely on Claude alone to decide priority.
Before invoking Amazon Bedrock, the Lambda function calculates a deterministic score for each finding. The scoring logic considers signals such as:
AWS severity
Fix availability
Exploit availability
Internet exposure indicators
IAM or privilege-related indicators
Production environment tags
Sensitive data classification tags
ECR container vulnerability category
The score is then mapped into operational priority levels:
P0 = immediate action required
P1 = high priority
P2 = planned remediation
P3 = backlog or hygiene item
This is a good security design decision.
AI can help explain, summarize, and recommend next steps. But the baseline priority should still come from logic the team can inspect, tune, and defend.
That matters for auditability. It also matters for trust.
If an engineer asks why a finding was marked P1 instead of P3, the answer should not be “because the model said so.” The answer should point back to observable risk factors such as severity, exploitability, exposure, production status, and data sensitivity.
How Claude Sonnet 4.6 Is Used
The Lambda function sends normalized findings to Amazon Bedrock using the Bedrock runtime client and the Converse API.
Claude is instructed to act as a senior cloud security architect and vulnerability management analyst.
The prompt includes strict guardrails:
Do not invent missing facts.
Do not assume a fix exists unless fix_available is explicitly YES.
Do not change finding IDs, account IDs, regions, or resource IDs.
Do not recommend destructive remediation.
Do not recommend automated containment unless the action is clearly reversible and low risk.
Return valid JSON only.
This is exactly the kind of boundary I want to see in a security automation.
The model is not being asked to blindly remediate anything. It is being asked to analyze already-filtered findings and return structured output that humans can review and act on.
The expected output includes:
Overall risk level
Executive summary
P0, P1, P2, and P3 counts
Key risk themes
Recommended management action
Prioritized findings
Business impact
Technical risk
Recommended fix
Remediation owner
Remediation SLA
Validation steps
Evidence required
Human approval requirement
Automation safety flag
Reasoning
This makes the output useful for two different audiences.
Managers get a readable summary of risk and priority.
Engineers get enough technical detail to begin remediation planning, validation, evidence collection, and ticket creation.
Reports Are Stored in S3
After analysis, the workflow writes reports to Amazon S3 in three formats:
JSON
HTML
CSV
The latest reports are written under:
latest/securityhub-ai-report-latest.json
latest/securityhub-ai-report-latest.html
latest/securityhub-ai-findings-latest.csv
The workflow also writes timestamped daily reports under a date-based prefix.
That gives the team two useful views:
- A current report for daily operations.
- Historical reports for trend review, audit support, and management reporting.
The deployment script also configures the S3 bucket with:
Public access block
Server-side encryption using AWS KMS
Bucket versioning
That is important because these reports may contain sensitive security information, including finding IDs, account IDs, affected resources, vulnerability references, and remediation details.
A security report is itself a sensitive asset. It should be protected accordingly.
Optional Security Hub Note Updates
The plan can update Security Hub findings with AI-generated priority metadata, but this feature is disabled by default.
The environment variable is:
UPDATE_SECURITYHUB_NOTES=false
There is a separate script to enable note updates after report quality is validated.
That is the safer approach.
Security Hub notes and user-defined fields can influence how teams interpret and manage findings. If those updates are enabled too early, poor-quality analysis could create confusion or misleading operational signals.
The recommended rollout path is:
- Generate reports with note updates disabled.
- Review the AI-generated prioritization.
- Compare the output against your existing remediation process.
- Tune scoring, prompts, filters, and ownership mapping.
- Enable Security Hub note updates only after the team trusts the output.
This keeps the workflow useful without letting it create uncontrolled changes in the security system of record.
Deployment Overview
The package includes CLI scripts for deployment and operations.
The main deployment script creates or updates:
S3 report bucket
IAM role and inline policy
Lambda function
EventBridge daily schedule
Lambda invoke permission for EventBridge
The Lambda runtime is configured as:
python3.12
The Lambda timeout is:
900 seconds
The memory size is:
1024 MB
The EventBridge rule runs daily using:
cron(0 1 * * ? *)
The package also includes operational scripts to:
Check model availability
Invoke the Lambda manually
Download latest reports
Update Lambda code
Set DAYS_BACK to 30
Enable Security Hub notes
Disable Security Hub notes
Check the EventBridge schedule
Tail Lambda logs
That makes the workflow practical to deploy and operate from AWS CloudShell or a terminal with AWS CLI configured.
This is important because security automation should be easy to test, easy to inspect, and easy to roll back.
What This Design Gets Right
The strongest part of this workflow is that it does not treat AI as the source of truth.
It uses deterministic filtering and scoring first, then uses Claude to produce structured analysis. That makes the output safer and more useful than sending raw findings directly to a model.
It also addresses a real cloud security pain point: ECR vulnerability noise from older images.
The output formats are practical too:
- HTML for managers and daily review.
- CSV for filtering, tracking, and ticketing.
- JSON for integration, automation, and evidence retention.
The fallback logic is another good design choice. If Bedrock analysis fails, the Lambda function still builds a deterministic fallback report instead of failing silently or producing nothing.
That matters in operations. A daily security report should degrade gracefully.
What I Would Validate Before Production Use
Before putting this into production, I would review these areas carefully.
Confirm Claude Sonnet 4.6 access in the target AWS Region or inference profile.
Review IAM permissions and reduce scope where possible.
Validate that the S3 bucket meets internal security requirements.
Run the workflow with Security Hub note updates disabled.
Compare generated priorities against real remediation decisions.
Confirm ECR latest image filtering matches your build and promotion process.
Tune DAYS_BACK and MAX_FINDINGS for your finding volume.
Review CloudWatch logs for Lambda errors and Bedrock invocation failures.
Restrict report access to authorized security and operations teams.
Define who owns P0, P1, P2, and P3 remediation follow-up.
Enable Security Hub note updates only after report quality is proven.
The most important production check is not whether the model can produce a polished report.
The most important check is whether the report leads to better security decisions.
Important Limitations
This workflow improves triage and reporting, but it does not remove the need for security judgment.
Claude can help summarize, prioritize, and recommend next steps. Human review is still required, especially where remediation could affect availability, compliance evidence, data access, or customer-facing systems.
The plan also does not perform automatic remediation. That is appropriate.
Security remediation can change production behavior. It can break workloads, rotate credentials, modify access, affect connectivity, or trigger compliance evidence requirements. Those actions need approval gates, rollback plans, and clear ownership.
The output should be treated as decision support, not an autonomous security control.
Practical Takeaway
This automation pattern is useful because it focuses on a real security operations problem:
Security teams have findings, but they need context, priority, ownership, and a clear path to action.
The design takes a balanced approach:
Use AWS-side logic to filter and normalize findings.
Use deterministic scoring to create a repeatable baseline.
Use Claude Sonnet 4.6 through Amazon Bedrock to generate structured analysis.
Store reports in S3 for daily review and historical tracking.
Keep Security Hub note updates disabled until the team validates quality.
For engineers, this can reduce manual triage effort.
For managers, it creates a clearer view of risk, priority, and remediation direction.
For the security program, it creates a more repeatable way to move from findings to action.
Final Thought
AI works best in security operations when it is placed inside a controlled workflow.
This plan does that well.
It does not ask Claude to replace the security team. It uses Claude to help the team read faster, prioritize better, and communicate risk more clearly.
That is the kind of AI-assisted security automation that can be useful in the real world.
Top comments (0)