Enriching Investigations with AWS Security Agent Findings
When to Use — AUTOMATIC ACTIVATION
Load this skill automatically when ANY of these conditions apply:
Application-Level Symptoms (even without explicit security context)
- Application pages or endpoints are not loading or returning errors
- Unexplained service outages with no recent deployments
- Application behaving unexpectedly without clear infrastructure cause
- Services returning 4xx/5xx errors without obvious resource exhaustion
Explicit Security Signals
- Security vulnerabilities or misconfigurations mentioned
- Suspicious code patterns or behaviors observed
- Authentication or authorization failures
- Injection vulnerabilities suspected (SQL, command, SSRF, etc.)
- Sensitive data exposure concerns
- Security-related errors in application logs
- Findings that suggest code-level security issues
Key Insight
Many security issues (like SSRF, injection attacks, or compromised dependencies) manifest as application outages or errors rather than obvious security alerts. When an app stops working and there's no clear infrastructure cause (no deployments, no resource exhaustion, no config changes), always check for security issues.
Overview
AWS Security Agent is an AI-powered security service that performs automated code security reviews and penetration testing. Its findings are stored in CloudWatch Logs and provide detailed, actionable information about vulnerabilities including exact file locations, line numbers, and remediation guidance.
Steps
Identify the relevant CloudWatch log group for AWS Security Agent findings. Look for log groups with patterns like:
/aws/securityagent/*- Log groups containing "security-agent" or "securityagent" in the name
Query the Security Agent logs using CloudWatch Logs Insights:
fields @timestamp, @message
| filter @message like /finding|vulnerability|issue|risk/
| sort @timestamp desc
| limit 100
Extract actionable details from the findings:
- File path: The exact source file containing the vulnerability
- Line number: The specific line(s) of code affected
- Vulnerability type: Classification (e.g., SQL injection, XSS, SSRF, hardcoded secrets)
- Severity: Critical, High, Medium, Low
- Description: What the vulnerability is and why it's a risk
- Remediation: Suggested fix or mitigation
Correlate findings with the incident by matching:
- Affected services or components
- Timeframes (when the vulnerability was introduced vs. when the incident occurred)
- Code paths involved in the failing functionality
Present findings to the customer with:
- Clear identification of the vulnerable code location
- Explanation of how this vulnerability may relate to the incident
- Specific remediation steps they can take to fix the code
Example Log Query for Specific Application
If investigating a specific application (e.g., "ssrf-demo", "orders", "account"):
fields @timestamp, @message
| filter @message like /ssrf|orders|account|vulnerability|finding|issue/
| sort @timestamp desc
| limit 50
Important Notes
- AWS Security Agent API access may require additional IAM permissions. If API calls fail, fall back to the CloudWatch logs approach.
- Always provide the exact file and line number when available — this is the key value for customers.
- Link the security finding to the observed incident behavior when possible.
- When in doubt, check security logs — it's better to rule out security issues than to miss them.
1---2name: enrich-with-aws-security-agent3description: Automatically load this skill when investigating application outages, service degradation, or errors that could have security-related root causes — including unexplained downtime, authentication or authorization failures, injection attacks, data exposure, or suspicious application behavior. Query AWS Security Agent CloudWatch logs to retrieve detailed code review findings with actionable, low-level details (file, line number, vulnerability type) that customers can directly fix.4---56# Enriching Investigations with AWS Security Agent Findings78## When to Use — AUTOMATIC ACTIVATION910**Load this skill automatically when ANY of these conditions apply:**1112### Application-Level Symptoms (even without explicit security context)13- Application pages or endpoints are not loading or returning errors14- Unexplained service outages with no recent deployments15- Application behaving unexpectedly without clear infrastructure cause16- Services returning 4xx/5xx errors without obvious resource exhaustion1718### Explicit Security Signals19- Security vulnerabilities or misconfigurations mentioned20- Suspicious code patterns or behaviors observed21- Authentication or authorization failures22- Injection vulnerabilities suspected (SQL, command, SSRF, etc.)23- Sensitive data exposure concerns24- Security-related errors in application logs25- Findings that suggest code-level security issues2627### Key Insight28Many security issues (like SSRF, injection attacks, or compromised dependencies) manifest as **application outages or errors** rather than obvious security alerts. When an app stops working and there's no clear infrastructure cause (no deployments, no resource exhaustion, no config changes), **always check for security issues**.2930## Overview3132AWS Security Agent is an AI-powered security service that performs automated code security reviews and penetration testing. Its findings are stored in CloudWatch Logs and provide detailed, actionable information about vulnerabilities including exact file locations, line numbers, and remediation guidance.3334## Steps35361. **Identify the relevant CloudWatch log group** for AWS Security Agent findings. Look for log groups with patterns like:37 - `/aws/securityagent/*`38 - Log groups containing "security-agent" or "securityagent" in the name39402. **Query the Security Agent logs** using CloudWatch Logs Insights:41 ```42 fields @timestamp, @message43 | filter @message like /finding|vulnerability|issue|risk/44 | sort @timestamp desc45 | limit 10046 ```47483. **Extract actionable details** from the findings:49 - **File path**: The exact source file containing the vulnerability50 - **Line number**: The specific line(s) of code affected51 - **Vulnerability type**: Classification (e.g., SQL injection, XSS, SSRF, hardcoded secrets)52 - **Severity**: Critical, High, Medium, Low53 - **Description**: What the vulnerability is and why it's a risk54 - **Remediation**: Suggested fix or mitigation55564. **Correlate findings with the incident** by matching:57 - Affected services or components58 - Timeframes (when the vulnerability was introduced vs. when the incident occurred)59 - Code paths involved in the failing functionality60615. **Present findings to the customer** with:62 - Clear identification of the vulnerable code location63 - Explanation of how this vulnerability may relate to the incident64 - Specific remediation steps they can take to fix the code6566## Example Log Query for Specific Application6768If investigating a specific application (e.g., "ssrf-demo", "orders", "account"):69```70fields @timestamp, @message71| filter @message like /ssrf|orders|account|vulnerability|finding|issue/72| sort @timestamp desc73| limit 5074```7576## Important Notes7778- AWS Security Agent API access may require additional IAM permissions. If API calls fail, fall back to the CloudWatch logs approach.79- Always provide the exact file and line number when available — this is the key value for customers.80- Link the security finding to the observed incident behavior when possible.81- **When in doubt, check security logs** — it's better to rule out security issues than to miss them.
aws