Sefism is free for learners. We are here to help you grow, one step at a time.Join for free
Sefism.
Security

AWS Misconfiguration Scanner with Attack Path Prioritisation for Startups

A read-only cloud security scanner for startups on AWS that finds misconfigurations such as public storage, over-broad IAM roles and open security groups, then links them into attack paths so a small team fixes the few that matter first. An intermediate cloud security final year project built on a graph model.

Topics
Difficulty

Intermediate

A small team, or one strong student willing to learn something new.
Effort

2 semesters · 3 students

Deliverables

7 to ship

3 optional extras

Suggested stack

Pythonboto3Neo4j or NetworkXPostgreSQLReactTerraformAWS IAM read-only roles
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • A read-only collector that assumes a customer-created IAM role with a documented minimal policy and inventories EC2, S3, IAM, RDS, Lambda, security groups and CloudTrail settings
  • At least 30 misconfiguration checks with severity, explanation and a fix (console steps and a Terraform snippet)
  • A resource graph linking internet exposure, compute, roles and data stores, with attack path queries such as "internet to instance to role to sensitive bucket"
  • A prioritised findings view that ranks issues by whether they sit on an attack path, not alphabetically or by raw count
  • A deliberately misconfigured test environment defined in Terraform in your own AWS account, used as ground truth
  • A comparison against Prowler on the same test environment: coverage, false positives and time to triage
  • A weekly diff report of new and fixed findings

If you have time left

  • Scan Terraform plans before apply and warn when a change would create a new attack path
  • Cost-aware findings, such as unused public IPs and idle resources, alongside security
  • Support for a second cloud provider for the three most common checks

The problem startups have with cloud security

A startup with five engineers sets up AWS fast. Someone makes an S3 bucket public to share a file with a client. An EC2 instance gets an IAM role with administrator access "for now". A security group opens a database port to the internet during debugging. None of these alone is a breach, but chained together they are: an exposed instance with a powerful role can read every bucket.

Existing scanners can find these issues, but they report hundreds of findings. A team with no security engineer cannot tell which five to fix this week, so they fix none.

What already exists and the gap

  • Prowler: open source AWS security and compliance scanner with broad check coverage, now with attack path features in its commercial offering.
  • ScoutSuite: open source multi-cloud audit tool that produces a static HTML report.
  • AWS Security Hub: native findings aggregation, useful but tied to AWS pricing and aimed at teams who already know how to triage.
  • Wiz and similar cloud security platforms: graph-based attack path analysis, priced for mid-size and large companies.

The gap is a scanner for a small team that does the prioritisation Wiz popularised, in a form a startup can afford and understand, with the fix for each finding written out.

What you build

Roles: account owner (connects AWS), engineer (fixes findings).

  1. Connect: the owner deploys a CloudFormation or Terraform template that creates a read-only role your service can assume. The policy is short and published.
  2. Collect: the collector inventories resources and relationships into a store.
  3. Check: rules evaluate each resource. Findings are stored with evidence.
  4. Connect the dots: the graph builder links internet-facing entry points, compute, identities and data stores. Queries find paths from the internet to sensitive data.
  5. Prioritise and fix: findings on attack paths rise to the top, each with a console fix and a Terraform snippet.

The technically interesting part

The graph model is the project. You must decide what a node is (resource, identity, policy), what an edge means (can reach over network, can assume, can read), and how to compute effective permissions from IAM policies well enough to be useful without writing a full policy evaluator. Start with a documented subset: identity policies with explicit allow and deny, no condition keys at first, and say clearly what you do not model.

Then show your supervisor a before-and-after: the flat list of findings from a standard scanner, and your ranked list, on the same deliberately broken environment.

How to evaluate it

  • Ground truth: your Terraform test environment contains a known set of planted misconfigurations and planted attack paths. Report detection rate for both.
  • Prioritisation: ask three engineers to triage the flat list and the ranked list for 15 minutes each. Count how many planted critical paths they identify.
  • Performance: collection and analysis time for an account with a few hundred resources.
  • Safety: prove the role cannot write anything by attempting write calls in tests and showing they are denied.

Suggested plan

  1. Weeks 1 to 4: learn AWS IAM and networking basics, write the Terraform test environment.
  2. Weeks 5 to 10: collector and first 15 checks.
  3. Weeks 11 to 16: graph model, effective permission subset, attack path queries.
  4. Weeks 17 to 21: prioritised UI, fixes, weekly diff.
  5. Weeks 22 to 26: comparison with Prowler, triage study, write-up.

Path to a product

The first customer is an early-stage startup preparing for its first enterprise customer's security questionnaire. Offer a free one-off scan and a monthly plan for continuous monitoring, priced per account rather than per resource. Software houses that run AWS for several clients are a second segment.

Scope warning

Only ever run against accounts that deployed your read-only role. Do not build exploitation or post-exploitation tooling. Do not try to support every AWS service; 8 services done well beat 40 done badly. Do not attempt a full IAM policy evaluator.

Learn what you need on Sefism

Get help with this idea

Scoping a security project is mostly about deciding what you will not defend against and how you will prove the rest works. If you want a second opinion on scope, stack or your evaluation plan, a mentor can review it with you; you still build it yourselves. New to Sefism? Create a free account first.

Ideas and guidance, not finished projects

These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.

Not sure this one fits you?

I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.

Discuss this idea
Work with me

Stuck on something specific?

Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.

Book a free sessionSee all services

Follow along

New writing, resources and project ideas land here first.