Did We Implement This Wrong, or Does AWS Expect You to Stitch the Findings Together Yourself?

If you have ever shipped a new AWS security stack—GuardDuty, Security Hub, Inspector, IAM Access Analyzer—and then opened the console to a wall of unrelated findings, the question feels inevitable: _Did we configure this wrong, or does AWS actually expect us to stitch the findings together ourselves?_

The short answer: no, you did not implement it wrong. AWS expects you to do the stitching.

But the real answer is more useful: AWS treats security findings as signals, not as an investigation. Once you accept that, you can build a much smaller and more reliable path from raw finding to action.

The gap is not in your AWS configuration

AWS security services are unusually good at producing specific, low-level findings. The problem is that they stop at the boundary of the service.

**Amazon GuardDuty** identifies anomalous API calls, suspicious S3 access, or credential exfiltration. It does not map that behavior to the full identity chain, the policies that allowed it, or every resource the identity touched afterward.

**Amazon Inspector** finds vulnerable packages and exposed network paths. It does not tell you which container is public, which team owns the image, or whether a vulnerable library is actually reachable.

**IAM Access Analyzer** flags roles and buckets that are shared with external accounts. It does not connect those permissions to a specific deployment, data classification, or live traffic pattern.

**AWS Security Hub** aggregates these findings into a single compliance console. It does not turn them into a timeline or root cause.

None of these services are broken. They are scoped.

AWS is intentionally primitive-first

AWS follows the same design philosophy across the platform: expose primitives and telemetry, and let customers own the interpretation. The AWS Shared Responsibility Model says AWS is responsible for security _of_ the cloud; you are responsible for security _in_ the cloud. Interpreting findings is part of your side.

Security Hub is often described as a central place to manage security and compliance across AWS accounts. Centralization is not correlation. Aggregation gives you one inbox. It does not give you one story.

That design has real benefits:

You can consume findings programmatically without being locked into a vendor opinion.

You can define severity based on your environment, not a generic label.

You can avoid the false confidence that comes from a single dashboard.

The tradeoff is that useful security work starts only after the finding lands.

What stitching actually looks like

Correlation works only as well as the identity and resource model underneath it. A practical pipeline looks like this.

1. Normalize findings into a common shape

Start with finding type, resource ARN, identity ARN, account, region, timestamp, severity, and status. This is table stakes for any downstream automation.

2. Enrich with ownership and deployment context

Fetch tags, CloudFormation stack names, repository metadata, team ownership, environment, and data classification. A critical vulnerability in an isolated dev container is not the same risk as one in a public production API.

3. Correlate across time and signals

Ask questions like:

Did this identity trigger GuardDuty, then create access keys, then read from an S3 bucket?

Is this exposed security group attached to an EC2 instance that also has a known Inspector vulnerability?

Does this same resource appear in multiple Security Hub findings from different sources?

4. Deduplicate and route

Send one enriched event to the right owner through Slack, Jira, PagerDuty, or a Lambda remediation workflow. Do not page a human for every raw finding.

5. Suppress by design, not by noise

Use EventBridge rules or Security Hub suppression rules to filter findings that are expected or already compensated by another control. That is how you keep the signal-to-noise ratio sane.

A concrete example: credential exfiltration

Say GuardDuty raises `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`.

A raw-console workflow looks like this:

Open GuardDuty and read the finding JSON.

Open CloudTrail and search for the same access key ID.

Open IAM and inspect the role policies.

Open VPC and check what the instance can reach.

Try to decide whether the instance had access to anything important.

A correlated workflow should answer:

Which environment and service is this instance part of?

What other activity did this role perform in the last hour?

Did this identity already appear in IAM Access Analyzer or Trusted Advisor?

Who owns the service, and what is the correct remediation path?

The first workflow is manual forensics. The second is a product decision. AWS provides the events for the second workflow, but it does not package the workflow itself.

Why Security Hub is not enough

Enable Security Hub and it is tempting to assume the problem is solved. Security Hub gives you centralized finding ingestion from GuardDuty, Inspector, Macie, and Config. It gives you the AWS Security Finding Format and compliance checks mapped to standards like CIS AWS Foundations Benchmark.

It does not give you automatic root-cause analysis, a timeline of related findings, business context such as team ownership or data classification, or prescriptive remediation for your architecture.

Security Hub is an excellent backbone. But if you treat it as the end of the pipeline instead of the beginning, you will always feel like you configured something wrong.

Practical first steps

If you are currently in the _did we do this wrong?_ phase, start here.

Accept raw findings as normal

A newly enabled detection stack often returns hundreds or thousands of findings. That is usually expected. Prioritize by exploitability and environment, not by count.

Build one correlation table

Start with a simple DynamoDB table or data warehouse view that links `resource_arn`, `identity_arn`, `finding_type`, `first_seen`, `last_seen`, `owner`, and `environment`. It does not have to be a graph database on day one.

Create an enrichment function

Use EventBridge and a Lambda function to add tags and ownership when each finding arrives. If you cannot tag everything retroactively, start with production and public-facing resources.

Tune Security Hub

Use suppression rules for expected findings and create custom insights that reflect your actual priorities, such as exposed public S3 buckets in production or GuardDuty high-severity findings for production accounts.

Connect CloudTrail

Most security stories are identity stories. CloudTrail is the best source of identity behavior. Joining findings to CloudTrail activity is often the highest-leverage correlation step you can make.

The uncomfortable answer

You did not implement it wrong. AWS gives you excellent building blocks, but it deliberately stops short of stitching them together. That gap is not a bug in your configuration—it is a boundary in AWS design.

For some teams, that boundary is acceptable because they already run a SIEM or SOAR. For everyone else, the answer is either build a correlation layer or use a product that treats AWS findings as raw material rather than the final result.

We built Sapior for exactly this reason: to take GuardDuty, Security Hub, Inspector, Access Analyzer, and CloudTrail findings and turn them into a single prioritized timeline—not another dashboard where someone has to copy ARNs between tabs.

The moment you stop expecting AWS to give you the story and start giving it the raw material, the findings become a lot less overwhelming.

References

[AWS Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)

[Amazon GuardDuty finding format](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings.html)

[AWS Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/)