bug bountycloudhow-to

Running a Bug Bounty for Infrastructure: Scope, Triage, and False Positive Playbooks

nnet work

2026-02-01

11 min read

A practical guide for DevOps teams launching infrastructure-focused bug bounties (AWS EU-sov): scope templates, triage automation, and false-positive playbooks.

Hook: Why your next bug bounty must include infrastructure — and why you’re behind if it doesn’t

For DevOps teams managing hybrid and sovereign-cloud deployments, the most damaging vulnerabilities no longer live in web forms — they live in IAM roles, mis-scoped trust policies, leaked Terraform state, and cross-account automation. Manual triage and ad-hoc scopes slow response and create expensive false positives. If you’re planning a bug bounty in 2026 that ignores cloud infrastructure (especially AWS EU Sovereign or other sovereign regions), you will miss critical findings and expose your organization to regulatory and operational risk.

This guide is a practical, hands-on how-to for launching infrastructure-focused bug bounties: defining scope for cloud infra (including AWS EU-sov), building a triage intake and automation pipeline, and writing a false-positive playbook so your security and DevOps teams can scale. You’ll get concrete scope templates, automation patterns, and sample code to enrich and triage reports automatically with AWS telemetry and platform APIs (Bugcrowd / HackerOne).

Executive summary (what to do first)

Define clear authorization boundaries — scope by account, role, and resource type, including explicit legal and operations guardrails for sovereign regions.
Prioritize automation for intake — enrich every report with CloudTrail/Config/GuardDuty context automatically via a webhook -> Lambda -> SIEM/issue flow.
Create a false-positive playbook with rule-based and evidence-based checks to fast-reject or auto-classify low-risk findings.
Instrument IaC and CI/CD to be in-scope where relevant, and require PoC steps that don’t perform destructive actions.
Measure outcomes by mean time to validate (MTTV), triage cost per report, and validated vuln count.

The 2026 context: Why infra bounties matter now

In late 2025 and early 2026 the cloud landscape shifted in three ways that directly affect bug bounties:

AWS launched dedicated European Sovereign regions and assurances to meet data-sovereignty requirements — making region-specific authorization and legal language essential in programs targeting EU customers.
Organizations expanded infrastructure-as-code (IaC) adoption and automated drift detection; attackers targeted misconfigured CI/CD secrets and Terraform state files more frequently than application-level XSS/SQLi in many verticals.
Bug-bounty platforms (Bugcrowd, HackerOne) formalized infrastructure program support and APIs for automated triage and enrichment in 2024–2026, making integration practical and scalable.

Planning and scope: templates and examples

A precise scope is the single biggest determinant of program quality. Below are three battle-tested templates you can adapt. Each template follows the same pattern: explicit assets, authorized techniques, forbidden actions, and data handling rules for sovereign regions.

Core scope elements (applies to all templates)

Authorized accounts and regions: List AWS accounts and ARNs (or organization unit IDs) that are in-scope. For EU sovereign, list the specific region codes (e.g., eu-sov-1) and note legal constraints.
Resource types in-scope: IAM, S3, EKS, RDS, Lambda, VPC configurations, Transit Gateway routing, KMS key policies.
In-scope techniques: misconfig discovery, principle-of-least-privilege violations, cross-account role misuse, exploitation of metadata endpoints, SSRF leading to metadata access, Terraform state exposure, CI/CD secret exposure (non-destructive).
Out-of-scope: Denial-of-service, destructive actions, social engineering, any attempt to access production PII outside PoC, and scoped third-party SaaS unless explicitly listed.
Proof-of-concept requirements: Step-by-step reproducible PoC, artifact (screenshots, logs, CloudTrail event IDs), minimal exploitation cadence, and a cleanup confirmation.

Template A — Small cloud-first startup (single account)

In-scope: single AWS account (account ID), regions: eu-west-1, eu-sov-1 (if deployed).
Resources: S3 buckets, IAM users/roles, ECR repos, ECS/EKS clusters, Lambda functions.
Out-of-scope: CI/CD runner global secrets, partner integrations, and any testing of paid 3rd-party APIs.

Template B — Regulated fintech using AWS EU-sov

In-scope: multiple AWS accounts (list), specific OU in AWS Organizations, region constrained to eu-sov-1 for data residency.
Resources: KMS key policies, IAM roles used by payment processing, RDS instances, VPC peering and Transit Gateway configurations.
Additional constraints: No testing that touches customer data; all PoC must be performed against staging accounts mirrored to EU-sov where possible; legal pre-approval required for any cross-account actions.

Template C — Enterprise hybrid cloud

In-scope: Multi-cloud accounts, on-prem systems accessible via VPN (list IP ranges), and CI/CD systems (GitHub/GitLab) for IaC repositories.
Resources: Identity providers (IdP), Terraform state in S3, secrets in Parameter Store/Secrets Manager, EKS clusters and node autoscaling policies.
Out-of-scope: Windows domain controllers and SOCS systems without explicit authorization.

Vulnerability intake: required fields and evidence

Standardize intake to reduce duplicate reports and improve automation. Require structured evidence so automated enrichment can act fast.

Reporter contact (platform username + email) and their PGP key if required.
In-scope asset identifier (account ID, region, ARN, IP, Kubernetes namespace, repo URL).
Repro steps with precise API calls (curl/boto3/gh cli) and timestamps.
PoC artifacts: CloudTrail event IDs, Request IDs, screenshots, short video, logs, or exploit scripts (non-sensitive).
Impact assessment: data exfiltration, privilege escalation, RCE, account takeover, etc.

Triage automation architecture (pattern & sample code)

Automate enrichment and classification to reduce manual triage cost. The standard pattern is:

Bug platform webhook (Bugcrowd/HackerOne) triggers an ingestion service.
Ingestion service calls cloud telemetry APIs (CloudTrail, Config, Security Hub, GuardDuty, IAM Access Analyzer) for the asset and time window provided.
Run deterministic checks (Is the S3 public? Is the role trust policy wildcarded? Does this CloudTrail show cross-account AssumeRole?)
Enrich the report with evidence and a suggested severity; forward to ticket system (Jira / ServiceNow) and to Slack/Teams for on-call review.

Sample serverless enrichment flow (AWS)

Key components:

API Gateway endpoint accepting platform webhooks
Lambda (Python) to orchestrate checks
Calls to AWS SDK (boto3) for CloudTrail, Config, SecurityHub
Connector to Bugcrowd/HackerOne API to post status updates
Jira ticket creation with attachments

import json
import boto3
import requests

def lambda_handler(event, context):
    body = json.loads(event['body'])
    asset = body.get('asset')
    account = body.get('account')

    # Quick enrichment: CloudTrail lookup
    ct = boto3.client('cloudtrail')
    events = ct.lookup_events(LookupAttributes=[{'AttributeKey':'ResourceName','AttributeValue': asset}], MaxResults=5)

    # IAM policy check sample
    iam = boto3.client('iam')
    try:
        role = iam.get_role(RoleName='ExampleRole')
        # inspect role['Role']['AssumeRolePolicyDocument']
    except Exception as e:
        events.append({'note':'IAM role not found'})

    # Post back to bug platform (pseudo)
    requests.post('https://platform.api/notes', json={'report_id': body['id'], 'enriched_events': events})

    return {'statusCode':200,'body':'ok'}

The above is intentionally minimal. Production deployments should include rate limiting, retries, signed requests, and strict IAM roles for least privilege. For Bugcrowd and HackerOne, use their documented REST APIs to add notes and change report status. Both platforms support programmatic evidence attachment and status updates.

Rule-based fast-fail and false positive playbook

False positives are the single biggest drain on triage teams. A false-positive playbook combines deterministic checks, evidence rules, and a manual-review escalation path.

Automated FP detection rules (examples)

S3 bucket reported as public but has website hosting with index.html only (check: object list + ACLs + bucket policy) — if no credentials exposed and no sensitive file patterns, mark as informational.
CloudTrail event shows an AssumeRole by a trusted internal automation principal — auto-tag as "internal-automation" and deprioritize unless PoC shows privilege escalation.
IAM policy contains wildcard resource but has Conditional context (e.g., aws:SourceIp) — assign manual review but include context in triage notes.
Findings in Terraform state file: if state is encrypted and access is not possible, flag as low impact; if state was exposed via public URL, escalate to high.

Manual FP playbook steps (triage checklist)

Validate asset identity: confirm account ID/ARN and region with CloudTrail lookup for the report timestamp.
Collect telemetry: CloudTrail events, VPC Flow Logs (if enabled), Security Hub findings, GuardDuty alerts, Config snapshots.
Run a safe PoC (non-destructive): read-only API call that demonstrates control (e.g., list-buckets, get-role) and attach output.
Apply automated FP rules; if rules match, notify reporter of classification and explain evidence. If not, escalate to SME.
Close or resolve with remediation steps, CVSS/impact, and retest instructions.

"Automate enrichment and you cut triage time by an order of magnitude. The human reviewers then focus on true complex cases instead of sorting noisy reports."

Safe PoC guidelines and legal considerations

Always protect customer data and avoid destructive tests. For EU sovereign environments, legal teams often require that PoC data remain within the sovereign region. Add this to your bounty terms and enforce it with your automation by rejecting PoCs that include data exported outside authorized regions.

Require PoCs to use dedicated staging or mirrored accounts when the finding could touch customer data.
Disallow exploitation that results in data exfiltration of real PII; allow reproduction of control-flow issues using synthetic data.
Provide ephemeral roles for researchers where possible (timeboxed, scoped) to reproduce cross-account trust issues.

Integrations and tools — what to use in 2026

Use a mix of the bug-bounty platform’s API, cloud telemetry, SIEM/SOAR, and CI/IaC scanning. Here are recommended integrations in 2026:

Bug Platforms: Bugcrowd and HackerOne — both now support infrastructure program models and webhooks for automation. Use their APIs to update report status and attach enrichment artifacts.
AWS native: Security Hub (aggregation), GuardDuty (threat detection), CloudTrail (audit), Config (drift/history), IAM Access Analyzer (cross-account findings), and the new EU-sov assurances for legal constraints.
IaC & CI/CD: Terraform Cloud/Enterprise, Terrascan/Checkov for pre-commit scanning, and GitHub/GitLab pipelines with enforced secret scanning.
SOAR/Orchestration: Cortex XSOAR, Splunk SOAR, or a lightweight Lambda-based workflow for evidence enrichment and ticketing.
Secrets & Entitlements: HashiCorp Vault, AWS Secrets Manager, and entitlement management platforms for detecting over-permissive roles.

Severity mapping and SLA for infra findings

Infrastructure findings require different severity logic than web bugs. Map severity to potential business impact and blast radius, not just CVSS. Example mapping:

Critical: Unauthenticated RCE or full cross-account compromise leading to customer data exfiltration or control of production (MTTR < 24 hours).
High: Privilege escalation or access to sensitive secrets (MTTR < 3 days).
Medium: Misconfig allowing limited access or information disclosure without PII (MTTR < 7 days).
Low/Info: Hardening suggestions, public metadata that does not expose secrets, or documentation gaps.

Measuring success: KPIs to track

Mean time to validate (MTTV) — goal: under 24 hours for critical reports.
Average triage cost per report — decreases as automation improves.
Validated vulnerabilities per program cycle — track density by resource type (IAM, S3, IaC, etc.).
False positive rate — aim under 15% within 90 days of launch.
Remediation lead time — time from validation to remediation across severity bands.

Operational example: automated enrichment + ticket flow (end-to-end)

Example sequence for a reported S3 bucket exposure:

Researcher files report with platform, including bucket name and timestamp.
Platform webhook triggers your ingestion API. The API validates the asset against your authorized scope manifest.
Lambda queries S3 ACLs, bucket policy, CloudTrail for ListObjects/GetObject events, and Config for historical changes.
Automation applies FP rules: if bucket only hosts static website assets and no sensitive patterns detected, classify as informational and notify reporter; otherwise create Jira ticket with evidence and suggested severity.
On-call DevOps receives Slack alert with ticket link and evidence. If confirmed, remediation owner tags sprint and schedules fix; automation posts status update to platform.

Final checklist before launching

Publish a precise scope with region/account ARNs and EU-sov constraints.
Document safe PoC guidelines and legal rules for sovereign data.
Deploy webhook -> enrichment pipeline and test with seeded reports.
Create a false-positive playbook and automate the most common rules.
Integrate with your ticketing and on-call system and run a dry run with a small researcher cohort.

Closing: the future of infrastructure bounties (2026 and beyond)

Infrastructure bug bounties will continue to mature from ad-hoc programs into an operational discipline integrated with DevOps. Expect richer platform APIs, region-aware legal tooling, and more automated evidence enrichment. Sovereign clouds such as AWS European Sovereign create both constraints and clarity — you must be explicit about regional authorization and telemetry residency.

The teams that win are those that treat the bounty program as an operational channel: fewer manual handoffs, automated triage, reproducible PoCs, and clear runbooks for false positives and remediation. Do that and you convert outside researchers into an extension of your security engineering team.

Actionable takeaways

Publish exact account/region ARNs and include EU-sov boundaries in your scope documentation before you go live.
Automate enrichment with CloudTrail, Config, GuardDuty and post evidence back to the bounty platform via API.
Ship a false-positive playbook that contains deterministic rules and a human escalation path.
Instrument IaC and CI/CD so findings in code or state are reproducible and testable without touching production data.

Call to action

Ready to launch an infrastructure bug bounty that scales? Start with our free checklist and Lambda enrichment starter kit tailored for AWS and EU sovereign environments. Visit net-work.pro/toolkits to download templates for scope documents, intake forms, and a production-ready enrichment Lambda you can adapt for Bugcrowd or HackerOne.

net work

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.