AWS Cloud Security Posture Scanner

Overview

This is a Python-based scanning tool that audits AWS environments for security misconfigurations across S3, IAM, VPC, and CloudTrail. It runs 21 checks, rates each finding by severity, and maps everything to the CIS AWS Foundations Benchmark. The full project is on GitHub with unit tests, a CI pipeline, and documentation.

I built this because I wanted to understand cloud security posture management at the code level, not just through a managed service’s dashboard. Tools like AWS Security Hub and GuardDuty surface findings, but writing the detection logic myself forced me to understand exactly what constitutes a misconfiguration and why it matters. The scanner checks for the same types of issues that show up in real-world cloud security assessments.

How It Works

The scanner is organized into four modules, each targeting a specific AWS service. Every module inherits from a base scanner class that standardizes how findings are recorded, rated, and formatted. This keeps the code consistent across services and makes it straightforward to add new scanners later.

S3 Scanner checks six misconfiguration types. It validates whether public access blocks are fully enabled, whether default encryption is configured, whether versioning is turned on, whether access logging is active, whether the bucket policy grants access to wildcard principals, and whether MFA delete is enabled on versioned buckets. Public access and wildcard principals are rated as critical because they directly expose data to the internet.

IAM Scanner covers seven checks that align with the identity security controls most organizations struggle with. It flags root account usage within the last 24 hours, IAM users with console access but no MFA, access keys older than 90 days, keys that haven’t been used in 90 days, policies granting full admin access (Action: * on Resource: *), users with inline policies instead of managed policies, and account password policies that don’t meet CIS requirements. The MFA and admin policy checks are both critical because a compromised account without MFA or with full admin permissions can result in complete environment takeover.

VPC Scanner evaluates five network-level configurations. It identifies security groups that allow SSH or RDP from 0.0.0.0/0 (the most common misconfiguration I’ve seen referenced in cloud security assessments), security groups with unrestricted egress, VPCs without flow logs enabled, and default security groups that still have active rules. Flow logs being disabled is rated as high because without them there’s no network-level visibility for forensics or threat detection.

CloudTrail Scanner handles three checks focused on logging integrity. It verifies that at least one trail has multi-region logging enabled and is actively recording, that log file validation is turned on to detect tampering, and that logs are encrypted with a KMS key. An account without multi-region CloudTrail logging has significant blind spots since any activity in a region without a trail goes unrecorded.

CIS Benchmark Mapping

Each finding maps to a specific control in the CIS AWS Foundations Benchmark v1.5. This isn’t just for documentation purposes. In a professional setting, security findings need to reference an established framework so that remediation can be prioritized against recognized standards. The S3 checks map to Section 2.1 controls, IAM checks map to Section 1 controls, VPC checks map to Section 5, and CloudTrail checks map to Section 3.

Testing

The unit tests use moto to mock AWS services so the entire test suite runs without an AWS account or any network calls. The tests create intentionally misconfigured resources in the mocked environment and then verify that the scanner correctly identifies and rates each finding. For example, one test creates an S3 bucket with a wildcard principal policy and confirms the scanner produces a critical-severity finding with the correct check ID.

CI/CD Pipeline

The GitHub Actions workflow runs on every push and pull request. It installs dependencies, runs flake8 for linting, runs Bandit to scan the Python code itself for security issues, and then executes the full pytest suite. If any step fails, the pipeline blocks the merge. The Bandit scan is intentional here because a security tool should hold its own code to the same standards it applies to infrastructure.

What This Demonstrates

This project covers several areas that come up in cloud security engineering roles. Writing the scanner required working directly with the boto3 API to understand how AWS surfaces configuration data for each service. The severity rating system required making judgment calls about which misconfigurations pose the highest risk, which is the same type of prioritization that happens during a real security assessment. The CIS mapping connects each finding to an industry-recognized standard, and the testing approach demonstrates that security tooling should be validated the same way application code is.

The scanner is also designed to exit with a non-zero code when critical findings are present, which means it can function as a gate in a CI/CD pipeline. Running it against a Terraform-provisioned AWS environment before deployment would catch misconfigurations in the same way that tfsec or Checkov catch IaC issues.