https://vulnerability.circl.lu/sightings/feed 2026-05-27T14:54:20.535063+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent sightings. https://vulnerability.circl.lu/sighting/1eeccfb6-5fc4-490f-9674-dd8ec5d676ac/export 2026-05-27T14:54:20.546070+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "1eeccfb6-5fc4-490f-9674-dd8ec5d676ac", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-42945", "type": "seen", "source": "https://bsky.app/profile/boredchilada.bsky.social/post/3mmmrecnkqz2f", "content": "~Checkpoint~\nHighlights include active exploitation of Cisco SD-WAN, Windows zero-days, and major ransomware breaches.\n-\nIOCs: CVE-2026-20182, CVE-2026-42945, YellowKey\n-\n#Ransomware #ThreatIntel #ZeroDay", "creation_timestamp": "2026-05-24T20:08:50.775262Z"} 2026-05-24T20:08:50.775262+00:00 https://vulnerability.circl.lu/sighting/a81d4d71-ecef-4971-a8b8-e1d9b8531925/export 2026-05-27T14:54:20.545968+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "a81d4d71-ecef-4971-a8b8-e1d9b8531925", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-42945", "type": "seen", "source": "Telegram/PWXxTbzLBS2I2NTEEZXYxWglH9J71PY-BvJO95sfjgRqY3E", "content": "", "creation_timestamp": "2026-05-25T03:00:10.000000Z"} 2026-05-25T03:00:10+00:00 https://vulnerability.circl.lu/sighting/010bda32-b354-4ace-813b-1d39dad1a1ea/export 2026-05-27T14:54:20.545867+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "010bda32-b354-4ace-813b-1d39dad1a1ea", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-42945", "type": "seen", "source": "Telegram/hq1WnakkbxJpSdatpwq9NAKRiUtHFa8ysgfQqaCqIO8mwqo", "content": "", "creation_timestamp": "2026-05-25T09:00:04.000000Z"} 2026-05-25T09:00:04+00:00 https://vulnerability.circl.lu/sighting/a5186743-292a-40b5-9dde-02c4bbf80646/export 2026-05-27T14:54:20.545747+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "a5186743-292a-40b5-9dde-02c4bbf80646", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-42945", "type": "seen", "source": "https://t.me/GithubRedTeam/85799", "content": "\ud83d\udea8 GitHub \u76d1\u63a7\u6d88\u606f\u63d0\u9192\n\n\ud83d\udea8 \u53d1\u73b0\u5173\u952e\u8bcd\uff1a #\u6f0f\u6d1e #CVE\n\n\ud83d\udce6 \u9879\u76ee\u540d\u79f0\uff1a NGINX-Rift\n\ud83d\udc64 \u9879\u76ee\u4f5c\u8005\uff1a nu0l\n\ud83d\udee0 \u5f00\u53d1\u8bed\u8a00\uff1a Unknown\n\u2b50 Star\u6570\u91cf\uff1a 0 | \ud83c\udf74 Fork\u6570\u91cf\uff1a 0\n\ud83d\udcc5 \u66f4\u65b0\u65f6\u95f4\uff1a 2026-05-25 09:02:51\n\n\ud83d\udcdd \u9879\u76ee\u63cf\u8ff0\uff1a\nCVE-2026-42945 NGINX \u5806\u6ea2\u51fa\u6f0f\u6d1e\u626b\u63cf\u4e0e\u9a8c\u8bc1\u5de5\u5177\n\n\ud83d\udd17 \u70b9\u51fb\u8bbf\u95ee\u9879\u76ee\u5730\u5740", "creation_timestamp": "2026-05-25T09:05:11.000000Z"} 2026-05-25T09:05:11+00:00 https://vulnerability.circl.lu/sighting/fb4cc2e6-7cc2-4624-b320-150be0fa69d8/export 2026-05-27T14:54:20.545309+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "fb4cc2e6-7cc2-4624-b320-150be0fa69d8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-42945", "type": "seen", "source": "https://gist.github.com/coquinone/369492f9b58b8ac7cd7c0946a83fb8c9", "content": "# Shift left with automated penetration testing: Integrating AWS Security Agent into your CI/CD pipeline\n\nAI is changing the vulnerability landscape fast. In May 2026, researchers at DepthFirst used an AI-assisted detection platform to uncover [NGINX Rift (CVE-2026-42945)](https://www.secure.com/news/nginx-18-year-old-rce-vulnerability), a critical heap buffer overflow that had been sitting in the NGINX codebase since 2008, affecting roughly a third of all websites on the internet. Around the same time, Microsoft announced their agentic security system found [16 new vulnerabilities in the Windows networking stack](https://www.microsoft.com/en-us/security/blog/2026/05/12/defense-at-ai-speed-microsofts-new-multi-model-agentic-security-system-tops-leading-industry-benchmark/), including four critical RCE flaws. CVE disclosure rates for some vendors jumped by up to 500% in Q1 2026 compared to the previous quarter, largely driven by AI-assisted discovery.\n\nThe message is clear: attackers and researchers are finding bugs faster than most teams can test for them. If your security validation still happens monthly (or worse, quarterly), you are falling behind. This is where \"shift left\" comes in: move security testing earlier in the development lifecycle and make it continuous, so vulnerabilities get caught before they reach production.\n\n[AWS Security Agent](https://aws.amazon.com/security-agent) provides on-demand penetration testing that you can trigger programmatically via APIs. It doesn't have a native CI/CD integration today, but it exposes public APIs (`StartPentestJob`, `BatchGetPentestJobs`, `ListFindings`, `BatchGetFindings`) that you can call from your pipeline. In this post, I walk through how to wire those APIs into a GitHub Actions workflow so every deployment gets automatically tested for vulnerabilities and blocked if critical issues are found.\n\n> **Note:** All code in this post is sample code for reference purposes. You should review, test, and modify it to suit your own environment, security requirements, and organisational standards before using in production.\n\nBy the end of this walkthrough, you will have a pipeline that deploys your application to staging, triggers an autonomous penetration test, waits for results, and enforces a quality gate, all without human intervention.\n\n## Overview\n\nIn most large organisations, there is usually a dedicated platform team or AppSec team that manages security tooling centrally. Individual application teams don't each host their own scanning infrastructure. Instead, the central team provisions and maintains shared tooling, and app teams just plug into it. This is the model we use in this post.\n\nThe integration follows a separation of responsibilities:\n\n- **Central security/platform team** provisions infrastructure (Agent Spaces, IAM roles, domain verification) using AWS CDK and maintains a shared GitHub Action that any app team can reference.\n- **Application teams** configure their pentest targets through the Security Agent Web Application and add a few lines of YAML to their existing pipeline. They don't need to understand the underlying infrastructure.\n\nThe repeatable pipeline flow looks like this:\n\n\n\n## Prerequisites\n\nBefore you start, make sure you have:\n\n- An AWS account with [AWS Security Agent](https://aws.amazon.com/security-agent) enabled\n- [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/) configured for user access to the Security Agent Web Application\n- A GitHub repository with GitHub Actions enabled\n- [AWS CDK](https://aws.amazon.com/cdk/) v2.170+ installed (for infrastructure deployment)\n- A staging environment for your application\n\n## Architecture and responsibility matrix\n\nOne thing worth calling out: there are two separate IAM roles involved, and they serve very different purposes:\n\n1. **Pentest execution role**: this one gets assumed by the AWS Security Agent service while it's actually running the tests. It needs access to CloudWatch Logs, Secrets Manager, and optionally Lambda functions for credential vending.\n2. **GitHub Actions role**: this one gets assumed by the GitHub runner via OIDC federation to call Security Agent APIs (`StartPentestJob`, `BatchGetPentestJobs`, `ListFindings`). It doesn't do any actual testing itself.\n\nHere is how responsibilities break down:\n\n| Activity | Owner | Frequency | Custom code? |\n|---|---|---|---|\n| Deploy Agent Space + IAM + Domain | Central team | Once per app | Yes (CDK) |\n| Install GitHub App integration | Central team | Once per org | No (Console) |\n| Upload docs & API specs | App team | Once (update as needed) | No (Web UI) |\n| Create pentest configuration | App team | Once per app | No (Web UI) |\n| Shared GitHub Action (`run-pentest`) | Central team | Built once | Yes |\n| Integrate action into pipeline | App team | Once | No (YAML config) |\n\n## Step 1: Provision infrastructure with AWS CDK\n\nThe central security team deploys all the infrastructure using AWS CDK (Python). The `aws_cdk.aws_securityagent` module provides L1 constructs for the required CloudFormation resource types. Nothing too fancy here, just standard CDK patterns.\n\n### CDK project structure\n\n```\nsecurity-agent-infra/\n\u251c\u2500\u2500 app.py\n\u251c\u2500\u2500 cdk.json\n\u251c\u2500\u2500 requirements.txt\n\u2514\u2500\u2500 stacks/\n \u251c\u2500\u2500 __init__.py\n \u251c\u2500\u2500 security_agent_app_stack.py\n \u2514\u2500\u2500 agent_space_stack.py\n```\n\n### Application stack (one per AWS account)\n\nThis stack deploys the top-level Security Agent Application resource. It configures IAM Identity Center so your team can access the Web Application.\n\n```python\n# stacks/security_agent_app_stack.py\n\nfrom aws_cdk import (\n Stack,\n CfnOutput,\n aws_securityagent as securityagent,\n aws_iam as iam,\n)\nfrom constructs import Construct\n\n\nclass SecurityAgentAppStack(Stack):\n def __init__(self, scope: Construct, construct_id: str,\n idc_instance_arn: str,\n kms_key_id: str = None,\n **kwargs) -> None:\n super().__init__(scope, construct_id, **kwargs)\n\n self.service_role = iam.Role(\n self, \"SecurityAgentServiceRole\",\n assumed_by=iam.ServicePrincipal(\"securityagent.amazonaws.com\"),\n description=\"Service role for AWS Security Agent\",\n )\n\n self.application = securityagent.CfnApplication(\n self, \"SecurityAgentApplication\",\n role_arn=self.service_role.role_arn,\n idc_configuration=securityagent.CfnApplication.IdCConfigurationProperty(\n idc_instance_arn=idc_instance_arn,\n ),\n default_kms_key_id=kms_key_id,\n tags=[{\"key\": \"ManagedBy\", \"value\": \"CDK\"}],\n )\n\n CfnOutput(self, \"ApplicationId\",\n value=self.application.attr_application_id)\n CfnOutput(self, \"WebAppDomain\",\n value=self.application.attr_domain)\n```\n\n### Agent Space stack (one per application)\n\nThis is where most of the per-application setup lives. It creates the Agent Space, target domain, pentest execution role, and the GitHub Actions OIDC role. I will break this into a few parts so it's easier to follow.\n\n```python\n# stacks/agent_space_stack.py\n\nfrom aws_cdk import (\n Stack, CfnOutput, RemovalPolicy,\n aws_securityagent as securityagent,\n aws_iam as iam,\n aws_logs as logs,\n aws_secretsmanager as secretsmanager,\n)\nfrom constructs import Construct\n\n\nclass AgentSpaceStack(Stack):\n def __init__(self, scope: Construct, construct_id: str,\n app_name: str,\n target_domain: str,\n service_role_arn: str,\n secret_arns: list[str] = None,\n **kwargs) -> None:\n super().__init__(scope, construct_id, **kwargs)\n\n # CloudWatch Log Group for pentest execution logs\n self.log_group = logs.LogGroup(\n self, \"PentestLogGroup\",\n log_group_name=f\"/aws/securityagent/{app_name}\",\n retention=logs.RetentionDays.ONE_YEAR,\n removal_policy=RemovalPolicy.RETAIN,\n )\n\n # Role assumed by Security Agent during testing\n self.pentest_role = iam.Role(\n self, \"PentestExecutionRole\",\n role_name=f\"SecurityAgent-{app_name}-PentestRole\",\n assumed_by=iam.ServicePrincipal(\"securityagent.amazonaws.com\"),\n )\n self.log_group.grant_write(self.pentest_role)\n\n if secret_arns:\n for secret_arn in secret_arns:\n secret = secretsmanager.Secret.from_secret_complete_arn(\n self, f\"Secret-{secret_arn[-8:]}\",\n secret_complete_arn=secret_arn\n )\n secret.grant_read(self.pentest_role)\n```\n\nThe GitHub Actions role uses OIDC federation so you don't need to store any long-lived credentials in GitHub:\n\n```python\n # Role assumed by GitHub runner to trigger/monitor pentests\n self.github_action_role = iam.Role(\n self, \"GitHubActionRole\",\n role_name=f\"GitHubActions-{app_name}-Pentest\",\n assumed_by=iam.FederatedPrincipal(\n \"token.actions.githubusercontent.com\",\n conditions={\n \"StringEquals\": {\n \"token.actions.githubusercontent.com:aud\": \"sts.amazonaws.com\"\n },\n \"StringLike\": {\n \"token.actions.githubusercontent.com:sub\": \"repo:your-org/*:*\"\n },\n },\n assume_role_action=\"sts:AssumeRoleWithWebIdentity\",\n ),\n )\n self.github_action_role.add_to_policy(iam.PolicyStatement(\n actions=[\n \"securityagent:StartPentestJob\",\n \"securityagent:BatchGetPentestJobs\",\n \"securityagent:ListFindings\",\n \"securityagent:BatchGetFindings\",\n ],\n resources=[\"*\"],\n ))\n```\n\nFinally, the target domain and Agent Space resources. This is where everything comes together:\n\n```python\n # Target domain registration\n self.target_domain = securityagent.CfnTargetDomain(\n self, \"TargetDomain\",\n target_domain_name=target_domain,\n verification_method=\"DNS_TXT\",\n )\n\n # Agent Space\n self.agent_space = securityagent.CfnAgentSpace(\n self, \"AgentSpace\",\n name=app_name,\n description=f\"Security testing workspace for {app_name}\",\n target_domain_ids=[self.target_domain.attr_target_domain_id],\n aws_resources=securityagent.CfnAgentSpace.AWSResourcesProperty(\n iam_roles=[self.pentest_role.role_arn],\n log_groups=[self.log_group.log_group_arn],\n secret_arns=secret_arns or [],\n ),\n )\n\n # Outputs for the application team\n CfnOutput(self, \"AgentSpaceId\",\n value=self.agent_space.attr_agent_space_id)\n CfnOutput(self, \"GitHubActionRoleArn\",\n value=self.github_action_role.role_arn)\n```\n\n### CDK app entry point\n\n```python\n# app.py\n\nimport aws_cdk as cdk\nfrom stacks.security_agent_app_stack import SecurityAgentAppStack\nfrom stacks.agent_space_stack import AgentSpaceStack\n\napp = cdk.App()\nenv = cdk.Environment(account=\"123456789012\", region=\"ap-southeast-2\")\n\n# Account-level setup (deploy once)\napp_stack = SecurityAgentAppStack(\n app, \"SecurityAgentApp\",\n idc_instance_arn=\"arn:aws:sso:::instance/ssoins-xxxxxxxxxxxx\",\n kms_key_id=\"arn:aws:kms:ap-southeast-2:123456789012:key/mrk-xxxx\",\n env=env,\n)\n\n# Per-application Agent Space\nAgentSpaceStack(\n app, \"AgentSpace-payments-api\",\n app_name=\"payments-api\",\n target_domain=\"staging-payments.example.com\",\n service_role_arn=app_stack.service_role.role_arn,\n secret_arns=[\n \"arn:aws:secretsmanager:ap-southeast-2:123456789012:secret:pentest/payments-api-creds\"\n ],\n env=env,\n)\n\napp.synth()\n```\n\nDeploy with:\n\n```bash\npip install aws-cdk-lib constructs\ncdk deploy --all\n```\n\nAfter deployment, note the `AgentSpaceId` and `GitHubActionRoleArn` outputs. You will need to provide these to the application team.\n\n### Connect GitHub (console)\n\nThe GitHub App installation is a manual step in the AWS Console. Can't automate this part unfortunately:\n\n1. Navigate to **AWS Security Agent** \u2192 **Integrations**\n2. Choose **Add Integration** \u2192 **GitHub**\n3. Install the AWS Security Agent GitHub App into your GitHub organisation\n4. Authorise access to the required repositories\n\n## Step 2: Configure pentest targets (application team)\n\nThe application team does their setup entirely through the Security Agent Web Application. No custom code needed here.\n\nAfter receiving the `AgentSpaceId` and Web Application URL from the central team:\n\n1. **Log in** to the Security Agent Web Application using IAM Identity Center credentials\n2. **Select the Agent Space** created by the central team\n3. **Upload context artefacts**: architecture diagrams, OpenAPI specs, threat models. These help the agent build deeper understanding of your application for more targeted testing. Supported formats include PDF, YAML, JSON, Markdown, PNG, and DOCX.\n4. **Create a pentest configuration:**\n - Set a title (e.g., \"Payments API - CI/CD Pentest\")\n - Add target endpoints (e.g., `https://staging-payments.example.com`)\n - Configure actors with authentication credentials (referencing your Secrets Manager secret)\n - Select which risk types to include or exclude\n - Optionally enable automatic code remediation (creates PRs in GitHub)\n5. **Note the `pentestId`**. You'll need this for the pipeline.\n\nThen store these as GitHub repository secrets:\n\n| Secret Name | Value | Source |\n|---|---|---|\n| `AGENT_SPACE_ID` | `asp-xxxxxxxxxxxx` | CDK output (from central team) |\n| `PENTEST_ID` | `pt-xxxxxxxxxxxx` | Web UI (after creating pentest config) |\n| `PENTEST_ROLE_ARN` | `arn:aws:iam::...:role/GitHubActions-payments-api-Pentest` | CDK output: `GitHubActionRoleArn` |\n\n## Step 3: Build the shared GitHub Action\n\nThe central team maintains a reusable composite GitHub Action in a shared repository (e.g., `your-org/security-actions`). This action handles the full lifecycle: trigger the pentest, poll for completion, extract findings, and enforce a quality gate. Once built, every app team in your organisation can reference it.\n\nThe action calls these AWS Security Agent APIs:\n\n| API | Purpose |\n|---|---|\n| `StartPentestJob` | Trigger the penetration test |\n| `BatchGetPentestJobs` | Poll for job completion status |\n| `ListFindings` | Retrieve finding summaries for the quality gate |\n| `BatchGetFindings` | (Optional) Get full finding details for reporting |\n\n### Action definition\n\n```yaml\n# .github/actions/run-pentest/action.yml\nname: 'AWS Security Agent - Run Pentest'\ndescription: 'Triggers an AWS Security Agent pentest and reports results'\ninputs:\n agent-space-id:\n description: 'AWS Security Agent Space ID'\n required: true\n pentest-id:\n description: 'Pentest configuration ID'\n required: true\n aws-region:\n description: 'AWS region'\n required: false\n default: 'ap-southeast-2'\n poll-interval:\n description: 'Seconds between status polls'\n required: false\n default: '60'\n timeout-minutes:\n description: 'Maximum wait time in minutes'\n required: false\n default: '120'\n fail-on-critical:\n description: 'Fail if CRITICAL findings with HIGH confidence exist'\n required: false\n default: 'true'\n fail-on-high:\n description: 'Fail if HIGH findings with HIGH confidence exist'\n required: false\n default: 'true'\n include-full-details:\n description: 'Include full finding details in output'\n required: false\n default: 'false'\noutputs:\n pentest-job-id:\n description: 'The pentest job ID'\n value: ${{ steps.run.outputs.pentest-job-id }}\n status:\n description: 'Final job status'\n value: ${{ steps.run.outputs.status }}\n findings-count:\n description: 'Total findings'\n value: ${{ steps.run.outputs.findings-count }}\n critical-count:\n description: 'CRITICAL findings count'\n value: ${{ steps.run.outputs.critical-count }}\n high-count:\n description: 'HIGH findings count'\n value: ${{ steps.run.outputs.high-count }}\n results-file:\n description: 'Path to results JSON'\n value: ${{ steps.run.outputs.results-file }}\nruns:\n using: 'composite'\n steps:\n - name: Run Pentest\n id: run\n shell: bash\n env:\n AGENT_SPACE_ID: ${{ inputs.agent-space-id }}\n PENTEST_ID: ${{ inputs.pentest-id }}\n AWS_REGION: ${{ inputs.aws-region }}\n POLL_INTERVAL: ${{ inputs.poll-interval }}\n TIMEOUT_MINUTES: ${{ inputs.timeout-minutes }}\n FAIL_ON_CRITICAL: ${{ inputs.fail-on-critical }}\n FAIL_ON_HIGH: ${{ inputs.fail-on-high }}\n INCLUDE_FULL_DETAILS: ${{ inputs.include-full-details }}\n run: python ${{ github.action_path }}/run_pentest.py\n```\n\n### Action script\n\nThe Python script implements the core logic. It goes through four phases that mirror the pentest job execution steps (PREFLIGHT \u2192 STATIC_ANALYSIS \u2192 PENTEST \u2192 FINALIZING). Let me walk through the key parts:\n\n```python\n#!/usr/bin/env python3\n# .github/actions/run-pentest/run_pentest.py\n\nimport boto3\nimport json\nimport os\nimport sys\nimport time\nfrom datetime import datetime, timezone\n\n\ndef get_env(name: str, default: str = None) -> str:\n value = os.environ.get(name, default)\n if value is None:\n print(f\"::error::Missing required env var: {name}\")\n sys.exit(1)\n return value\n\n\ndef set_output(name: str, value: str):\n output_file = os.environ.get('GITHUB_OUTPUT', '')\n if output_file:\n with open(output_file, 'a') as f:\n f.write(f\"{name}={value}\\n\")\n\n\ndef main():\n # Configuration\n agent_space_id = get_env('AGENT_SPACE_ID')\n pentest_id = get_env('PENTEST_ID')\n region = get_env('AWS_REGION', 'ap-southeast-2')\n poll_interval = int(get_env('POLL_INTERVAL', '60'))\n timeout_minutes = int(get_env('TIMEOUT_MINUTES', '120'))\n fail_on_critical = get_env('FAIL_ON_CRITICAL', 'true').lower() == 'true'\n fail_on_high = get_env('FAIL_ON_HIGH', 'true').lower() == 'true'\n include_details = get_env('INCLUDE_FULL_DETAILS', 'false').lower() == 'true'\n\n client = boto3.client('securityagent', region_name=region)\n\n # Step 1: Start the pentest job\n print(\"::group::Starting pentest job\")\n response = client.start_pentest_job(\n agentSpaceId=agent_space_id,\n pentestId=pentest_id\n )\n job_id = response['pentestJobId']\n print(f\" Job started: {job_id}\")\n print(\"::endgroup::\")\n set_output('pentest-job-id', job_id)\n\n # Step 2: Poll until completion\n print(\"::group::Polling for completion\")\n timeout_secs = timeout_minutes * 60\n start_time = time.time()\n terminal_states = {'COMPLETED', 'FAILED', 'STOPPED'}\n\n while True:\n elapsed = time.time() - start_time\n if elapsed > timeout_secs:\n print(f\"::error::Timeout after {timeout_minutes}m\")\n set_output('status', 'TIMEOUT')\n sys.exit(1)\n\n time.sleep(poll_interval)\n resp = client.batch_get_pentest_jobs(\n agentSpaceId=agent_space_id,\n pentestJobIds=[job_id]\n )\n job = resp['pentestJobs'][0]\n status = job['status']\n print(f\" [{int(elapsed/60)}m] Status: {status}\")\n\n if status in terminal_states:\n break\n\n print(\"::endgroup::\")\n set_output('status', status)\n\n if status == 'FAILED':\n err = job.get('errorInformation', {})\n print(f\"::error::Job failed: {err.get('message', 'Unknown')}\")\n sys.exit(1)\n```\n\nAfter the job completes, the script retrieves findings and applies the quality gate. This is the part that decides whether your pipeline passes or fails:\n\n```python\n # Step 3: Retrieve findings\n print(\"::group::Retrieving findings\")\n summaries = []\n next_token = None\n\n while True:\n params = {'agentSpaceId': agent_space_id, 'pentestJobId': job_id}\n if next_token:\n params['nextToken'] = next_token\n resp = client.list_findings(**params)\n summaries.extend(resp.get('findingsSummaries', []))\n next_token = resp.get('nextToken')\n if not next_token:\n break\n\n # Count by severity\n counts = {}\n for f in summaries:\n level = f.get('riskLevel', 'UNKNOWN')\n counts[level] = counts.get(level, 0) + 1\n\n critical = counts.get('CRITICAL', 0)\n high = counts.get('HIGH', 0)\n medium = counts.get('MEDIUM', 0)\n low = counts.get('LOW', 0)\n\n set_output('findings-count', str(len(summaries)))\n set_output('critical-count', str(critical))\n set_output('high-count', str(high))\n print(\"::endgroup::\")\n\n # Step 4: Write results JSON\n results = {\n 'metadata': {\n 'agentSpaceId': agent_space_id,\n 'pentestJobId': job_id,\n 'status': status,\n 'timestamp': datetime.now(timezone.utc).isoformat(),\n 'overview': job.get('overview', ''),\n },\n 'summary': {\n 'total': len(summaries),\n 'critical': critical,\n 'high': high,\n 'medium': medium,\n 'low': low,\n },\n 'findings': [\n {\n 'findingId': f.get('findingId'),\n 'name': f.get('name'),\n 'riskType': f.get('riskType'),\n 'riskLevel': f.get('riskLevel'),\n 'confidence': f.get('confidence'),\n 'status': f.get('status'),\n }\n for f in summaries\n ],\n }\n\n results_file = os.path.join(\n os.environ.get('GITHUB_WORKSPACE', '.'), 'pentest-results.json'\n )\n with open(results_file, 'w') as fh:\n json.dump(results, fh, indent=2, default=str)\n set_output('results-file', results_file)\n\n # Step 5: Quality gate\n gate_critical = [f for f in summaries\n if f.get('riskLevel') == 'CRITICAL'\n and f.get('confidence') == 'HIGH']\n gate_high = [f for f in summaries\n if f.get('riskLevel') == 'HIGH'\n and f.get('confidence') == 'HIGH']\n\n if fail_on_critical and gate_critical:\n print(f\"::error::BLOCKED: {len(gate_critical)} CRITICAL finding(s)\")\n sys.exit(1)\n if fail_on_high and gate_high:\n print(f\"::error::BLOCKED: {len(gate_high)} HIGH finding(s)\")\n sys.exit(1)\n\n print(\"Quality gate PASSED\")\n\n\nif __name__ == '__main__':\n main()\n```\n\nThe quality gate only fails on findings with **HIGH confidence**. This avoids blocking deployments on unconfirmed or low-confidence findings that might need manual review first. You can tune this behaviour with the `fail-on-critical` and `fail-on-high` inputs.\n\n## Step 4: Integrate into your pipeline\n\nWith the shared action in place, the application team just adds a workflow to their repository. This is the only file they need to create:\n\n```yaml\n# .github/workflows/deploy-and-pentest.yml\nname: Deploy & Pentest\n\non:\n push:\n branches: [main]\n pull_request:\n branches: [main]\n\npermissions:\n id-token: write\n contents: read\n pull-requests: write\n\nenv:\n AWS_REGION: ap-southeast-2\n\njobs:\n build-and-deploy:\n runs-on: ubuntu-latest\n outputs:\n deployed: ${{ steps.deploy.outputs.success }}\n steps:\n - uses: actions/checkout@v4\n - name: Build\n run: npm ci && npm run build\n - name: Configure AWS credentials\n uses: aws-actions/configure-aws-credentials@v4\n with:\n role-to-assume: ${{ secrets.DEPLOY_ROLE_ARN }}\n aws-region: ${{ env.AWS_REGION }}\n - name: Deploy to staging\n id: deploy\n run: |\n # Your deployment steps here\n echo \"success=true\" >> $GITHUB_OUTPUT\n\n pentest:\n runs-on: ubuntu-latest\n needs: build-and-deploy\n if: needs.build-and-deploy.outputs.deployed == 'true'\n steps:\n - name: Configure AWS credentials\n uses: aws-actions/configure-aws-credentials@v4\n with:\n role-to-assume: ${{ secrets.PENTEST_ROLE_ARN }}\n aws-region: ${{ env.AWS_REGION }}\n\n - name: Checkout shared actions\n uses: actions/checkout@v4\n with:\n repository: your-org/security-actions\n path: .github/shared-actions\n token: ${{ secrets.ACTIONS_PAT }}\n\n - name: Set up Python\n uses: actions/setup-python@v5\n with:\n python-version: '3.12'\n\n - name: Install dependencies\n run: pip install boto3\n\n - name: Run Penetration Test\n id: pentest\n uses: ./.github/shared-actions/run-pentest\n with:\n agent-space-id: ${{ secrets.AGENT_SPACE_ID }}\n pentest-id: ${{ secrets.PENTEST_ID }}\n fail-on-critical: 'true'\n fail-on-high: 'true'\n\n - name: Upload results\n if: always()\n uses: actions/upload-artifact@v4\n with:\n name: pentest-results-${{ github.run_id }}\n path: pentest-results.json\n retention-days: 90\n```\n\n### Adding PR comments\n\nFor pull request workflows, you can add a step that posts a summary comment directly on the PR. This way developers can see the results without leaving their normal workflow:\n\n```yaml\n - name: Comment on PR\n if: always() && github.event_name == 'pull_request'\n uses: actions/github-script@v7\n with:\n script: |\n const fs = require('fs');\n const results = JSON.parse(fs.readFileSync('pentest-results.json'));\n const s = results.summary;\n const status = s.critical > 0 || s.high > 0 ? '\u274c FAILED' : '\u2705 PASSED';\n const body = [\n `## \ud83d\udee1\ufe0f Pentest Results \u2014 ${status}`,\n `| Level | Count |`,\n `|---|---|`,\n `| \ud83d\udd34 Critical | ${s.critical} |`,\n `| \ud83d\udfe0 High | ${s.high} |`,\n `| \ud83d\udfe1 Medium | ${s.medium} |`,\n `| \ud83d\udd35 Low | ${s.low} |`,\n ``,\n `**Job:** \\`${results.metadata.pentestJobId}\\``,\n `**Overview:** ${results.metadata.overview || 'N/A'}`,\n ].join('\\n');\n github.rest.issues.createComment({\n issue_number: context.issue.number,\n owner: context.repo.owner,\n repo: context.repo.repo,\n body\n });\n```\n\nThis gives developers immediate visibility into security findings without leaving their pull request.\n\n## How the quality gate works\n\nThe quality gate logic is kept simple on purpose. It uses two dimensions from the `ListFindings` API response:\n\n| Field | Values | Purpose |\n|---|---|---|\n| `riskLevel` | CRITICAL, HIGH, MEDIUM, LOW, INFORMATIONAL | Severity of the vulnerability |\n| `confidence` | HIGH, MEDIUM, LOW, UNCONFIRMED, FALSE_POSITIVE | How certain the agent is |\n\nThe gate only blocks on findings where **both** the risk level is CRITICAL or HIGH **and** the confidence is HIGH. So in practice:\n\n- A CRITICAL finding with MEDIUM confidence \u2192 gets logged but does not block\n- A HIGH finding with HIGH confidence \u2192 blocks the deployment\n- A MEDIUM finding with HIGH confidence \u2192 gets logged but does not block\n\nThis reduces false-positive friction while still catching the confirmed severe vulnerabilities. Teams can adjust thresholds using the action inputs.\n\n## Results and reporting\n\nThe action writes a structured JSON file (`pentest-results.json`) that gets uploaded as a GitHub Actions artefact. This file contains:\n\n- **Metadata**: job ID, status, timestamp, and a natural-language overview of what got tested\n- **Summary**: counts by severity level\n- **Findings**: individual finding summaries with risk type, level, and confidence\n\nFor teams that need long-term retention or want to build dashboards, you can add an S3 upload step:\n\n```yaml\n - name: Upload to S3\n if: always()\n run: |\n aws s3 cp pentest-results.json \\\n s3://${{ secrets.RESULTS_BUCKET }}/pentest-results/${{ secrets.AGENT_SPACE_ID }}/${{ github.run_id }}/results.json\n```\n\nYou can then query these results with Amazon Athena for trend analysis across your application portfolio.\n\n## End-to-end onboarding flow\n\nHere is the complete sequence from initial request to automated testing:\n\n\n\n## Differences to traditional DAST solution\n\nTraditional dynamic application security testing (DAST) tools scan running applications without understanding their context. They just throw payloads at endpoints and see what sticks. AWS Security Agent takes a different approach:\n\n- **Context-aware testing**: When you upload architecture documents, API specs, and threat models, the agent builds a deep understanding of your application. It creates customised attack plans based on your specific business logic, not just generic vulnerability signatures.\n- **Adaptive execution**: The agent adjusts its attack strategy based on what it discovers during testing. If it finds an interesting endpoint or error response, it pivots to explore that path further.\n- **Multi-step attack chains**: Rather than testing individual inputs in isolation, the agent chains together multiple techniques. For example, combining server-side template injection with error forcing and debug output analysis to find more complex exploits.\n- **Authenticated testing**: By configuring actors with credentials from Secrets Manager, the agent tests your application as different user roles, uncovering authorisation and privilege escalation issues that unauthenticated scanning would miss.\n\n## Tips for production use\n\n**Start with a staging environment.** Point your pentest targets at a staging or pre-production environment that mirrors production. Even better, use a dedicated environment just for penetration testing. This makes sure the agent's testing doesn't affect real users.\n\n**Provide rich context.** The more context you give the agent (OpenAPI specs, architecture diagrams, threat models), the more targeted the testing becomes. Upload these through the Web Application when creating your pentest configuration.\n\n**Tune the timeout.** Pentest run duration depends on the breadth of the target application and the number of risk types configured. The [AWS Security Agent documentation](https://docs.aws.amazon.com/securityagent/latest/userguide/security-guidance.html) notes that runs can take up to 12 hours when all risk types are enabled. The default 120-minute timeout in the action works for narrowly scoped tests, but increase it (or narrow the scope of risk types in your pentest configuration) for comprehensive assessments.\n\n**Check service quotas before scaling.** AWS Security Agent has soft (adjustable) limits on concurrent pentest runs, agent spaces, and pentest projects per account per region. If you plan to onboard multiple application teams or run pentests on every PR, check the [AWS Security Agent service quotas](https://docs.aws.amazon.com/securityagent/latest/userguide/quotas.html) and request increases through AWS Support where needed.\n\n**Use branch protection rules.** Combine the pentest quality gate with GitHub branch protection rules so the pentest job must pass before merging to main.\n\n**Enable auto-remediation.** AWS Security Agent can automatically create pull requests with fixes for discovered vulnerabilities. You can enable this in the pentest configuration through the Web Application to close the loop faster.\n\n\n## Conclusion\n\nBy integrating AWS Security Agent into your CI/CD pipeline, penetration testing goes from a periodic manual bottleneck to a continuous automated practice. Every deployment gets tested. Critical vulnerabilities block releases before they reach production. Your security team can focus on strategic work instead of scheduling engagements.\n\nThe shift-left approach works here because the integration is lightweight for application teams. Just a few GitHub secrets and a workflow file, while the central team maintains the shared infrastructure and action. This scales across your organisation: onboard a new application by deploying one CDK stack and having the app team configure their targets through the Web UI.\n\nTo get started, visit the [AWS Security Agent console](https://console.aws.amazon.com/securityagent/) and create your first Agent Space. For more details on the service capabilities, see the [AWS Security Agent documentation](https://docs.aws.amazon.com/securityagent/latest/userguide/what-is.html).\n\n", "creation_timestamp": "2026-05-25T10:30:58.000000Z"} 2026-05-25T10:30:58+00:00 https://vulnerability.circl.lu/sighting/c650b090-be0d-4ec1-846a-2a5cd5c6e798/export 2026-05-27T14:54:20.545207+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "c650b090-be0d-4ec1-846a-2a5cd5c6e798", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-42945", "type": "seen", "source": "Telegram/-Rw1GdqgLbdPMkOwlVEIvz70NMtSIs0WWvrIrO5vIfavaPE", "content": "", "creation_timestamp": "2026-05-25T11:00:08.000000Z"} 2026-05-25T11:00:08+00:00 https://vulnerability.circl.lu/sighting/9701c1df-0a7c-464c-b858-7c4309328b17/export 2026-05-27T14:54:20.545095+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "9701c1df-0a7c-464c-b858-7c4309328b17", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-42945", "type": "seen", "source": "https://t.me/GithubRedTeam/85824", "content": "\ud83d\udea8 GitHub \u76d1\u63a7\u6d88\u606f\u63d0\u9192\n\n\ud83d\udea8 \u53d1\u73b0\u5173\u952e\u8bcd\uff1a #CVE-2026 #RCE\n\n\ud83d\udce6 \u9879\u76ee\u540d\u79f0\uff1a CVE-2026-42945-Nginx-RCE-bypass-ASLR\n\ud83d\udc64 \u9879\u76ee\u4f5c\u8005\uff1a bamov970\n\ud83d\udee0 \u5f00\u53d1\u8bed\u8a00\uff1a Python\n\u2b50 Star\u6570\u91cf\uff1a 1 | \ud83c\udf74 Fork\u6570\u91cf\uff1a 0\n\ud83d\udcc5 \u66f4\u65b0\u65f6\u95f4\uff1a 2026-05-25 12:21:49\n\n\ud83d\udcdd \u9879\u76ee\u63cf\u8ff0\uff1a\nCVE-2026-42945 turns a 17-year-old NGINX rewrite bug into remote code execution \u2014 even with ASLR on, by chaining the heap overflow with live worker memory read through a common file-read flaw.\n\n\ud83d\udd17 \u70b9\u51fb\u8bbf\u95ee\u9879\u76ee\u5730\u5740", "creation_timestamp": "2026-05-25T13:00:04.000000Z"} 2026-05-25T13:00:04+00:00 https://vulnerability.circl.lu/sighting/bcf0445f-4e13-4567-b563-557075e4dfd2/export 2026-05-27T14:54:20.544981+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "bcf0445f-4e13-4567-b563-557075e4dfd2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-42945", "type": "seen", "source": "Telegram/p4pSz48sW8Fl1dqUeH21RBDMwtfRPHmaTBryFak7xdWuTDY", "content": "", "creation_timestamp": "2026-05-25T15:00:06.000000Z"} 2026-05-25T15:00:06+00:00 https://vulnerability.circl.lu/sighting/d67887aa-89e9-4ed7-8c06-3cbe2fe8867f/export 2026-05-27T14:54:20.544816+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "d67887aa-89e9-4ed7-8c06-3cbe2fe8867f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-42945", "type": "seen", "source": "Telegram/X1Szwu_qpRNev2GcuASsATzQD-1aeqEPKRVacdyAUElWlBI", "content": "", "creation_timestamp": "2026-05-25T15:00:12.000000Z"} 2026-05-25T15:00:12+00:00 https://vulnerability.circl.lu/sighting/3e7ddbec-9727-4f6e-b020-be8903930fd3/export 2026-05-27T14:54:20.542537+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "3e7ddbec-9727-4f6e-b020-be8903930fd3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-42945", "type": "seen", "source": "https://bsky.app/profile/shortinfo.bsky.social/post/3mmozdjola72r", "content": "Server admins running NGINX should patch now. CVE-2026-42945 (NGINX Rift) is an 18-year-old heap buffer overflow in the rewrite module. Unauthenticated RCE possible where ASLR is weak. F5 patched May 13 (K000161019). Active exploitation in the wild.", "creation_timestamp": "2026-05-25T17:36:54.359496Z"} 2026-05-25T17:36:54.359496+00:00