aws-security-assessment-solution: a point in time Prowler scan you deploy yourself

The gap the solution fills: a fast assessment before the services are on

The README opens by naming the problem. Cybersecurity remains a very important topic and point of concern for many CIOs, CISOs and their customers, and AWS has developed a primary set of services customers should use to protect their accounts: Amazon GuardDuty, AWS Security Hub, AWS Config and AWS Well-Architected reviews.

Then it names the gap this project fills. As more organizations deploy to the cloud, especially if they are doing so quickly, and they have not yet implemented the recommended AWS services, there may be a need to conduct a rapid security assessment of the cloud environment.

So the tool is deliberately positioned before the managed services. It answers the question a new cloud team asks in week one, which is what does my account look like against AWS best practices, without waiting for a GuardDuty rollout or a Security Hub standards subscription.

The reports are generated using the open source project Prowler, which performs a point in time security assessment based on AWS best practices and can help quickly identify potential risk areas in a deployed environment.

The README also names the alternative for continuous work. For assessments on a continuous basis, AWS recommends enabling the Security Hub Foundational Security Best Practices standard, and for integrating Prowler results with Security Hub it points at the Prowler documentation.

That boundary is the most important thing for an adopter. This is a snapshot tool, and a snapshot tool that is run as a scheduled job is not the same as continuous monitoring with a managed standard.

The architecture: CloudFormation, CodeBuild, S3 and a Lambda trigger

The Overview section describes the deployment in one sentence, and it is a good architecture summary.

The solution is deployed with AWS CloudFormation. When deployed, an AWS CodeBuild project and an Amazon S3 bucket to store the Prowler generated reports are created, and an AWS Lambda function is then used to start the CodeBuild project.

So the flow is: CloudFormation creates the pieces, a user or an event invokes the Lambda, the Lambda starts the CodeBuild job, CodeBuild runs Prowler with the credentials it is given, and the reports land in the S3 bucket. The architecture diagram is in the repository as img/architecture.png.

The choice of CodeBuild rather than an EC2 instance is what makes this inexpensive and quick to deploy, and it is also the source of the main constraint. The scanning identity is whatever CodeBuild is running as, so getting that role right is the whole security design of the deployment, and the repository's top-level files show the shape of it: 1-sat2-member-roles.yaml for the member account roles and 2-sat2-codebuild-prowler.yaml for the CodeBuild project itself.

The timing is stated too. The deployment process takes less than 5 minutes to complete, and the default assessment takes around 5 minutes, with the time varying depending on the number of resources and the scan options selected. At the end of the assessments the reports are delivered to the created S3 bucket.

The default parameters run a basic scan in a single account, and the parameter defaults can be changed to run more extensive scans or to scan multiple accounts.

Scan types, and why the secrets checks are off by default

The Parameters section is where the operational choices live, and the table of CloudFormation parameters is where a deployer should start reading.

ProwlerScanType specifies which type of scan to perform, and the README notes that selecting full without specifying different ProwlerOptions will do a full scan, and that to perform a specific check you choose Full and append -c check to ProwlerOptions.

ExcludeSecretsChecks defaults to true, which skips the Prowler checks that search resource content for hardcoded secrets, and you set it to false to run them. That default deserves a moment of thought, because it is the kind of setting that is easy to leave alone and hard to regret. The checks in question read the content of your resources looking for credentials that were committed by mistake, and running them means the scanning process reads resource bodies, which is both slower and a larger data-handling question than a configuration-level check.

The README documents four scan types: Basic Scan, Intermediate scan, Full scan and Secrets checks. The secrets checks are the ones gated behind the parameter above, and the naming in the list is worth reading closely because it tells you that secrets checks are a separate mode rather than an addition to a full scan.

The deeper point about a pinned tool version is in the note about Prowler. The README states that Prowler is not an AWS owned solution, that customers should independently review Prowler before running this solution, and that any dependencies associated with Prowler should be kept up to date. It then explains why the solution pins a version: this solution installs a pinned version of Prowler, currently 5.41.0, from the pip package installer, so that a change to Prowler's output format cannot break a scan without warning. To move to a newer release you edit the pip3 install prowler== line in 2-sat2-codebuild-prowler.yaml.

Deployment paths: CloudShell, the console, and the multi-account route

The documentation is organised around two deployment styles and two account topologies, and the table of contents makes the shape clear.

For a single account, the README covers deployment from AWS CloudShell and from the AWS Console, each with its own deploy the solution step. The multi-account path is longer and has a prerequisite role step, a delegated administrator step for AWS Organizations, and then the solution deployment itself. The CloudShell route lists two steps for the multi-account case, a prerequisite role step and the solution deployment, while the console route adds a delegated administrator step in the middle.

That ordering is deliberate. The delegated administrator step is what lets one account scan others in the organization, and it has to exist before the solution is deployed, otherwise the cross-account role assumption fails at scan time rather than at deploy time.

The repository also carries a checks directory and a reporting directory alongside the templates, and the README's Reporting Summary section explains how the Athena table is built, with a subsection on scan history and duplicates. So the output is not just a pile of JSON files: the reporting side builds a table, which is what makes the results queryable afterwards rather than something you have to open file by file.

There is a Notifications section too, and a Clean Up section, and a Security section, which are the three things a template-based deployment on someone else's account usually needs and often lacks.

For a deeper walkthrough, the README points to module 2 of the SHIP Workshop.

Reading the results, and the gap between a report and a posture

The Review the results section names two ways to look at the findings, and the first one is labelled recommended.

The SATv2 Dashboard is the recommended path, and the Prowler Dashboard is the alternative. The distinction is worth understanding before you deploy. The Prowler dashboard is Prowler's own output and it tells you what Prowler found. The SATv2 dashboard is the solution's own view, which is presumably why it is recommended, since it is the part that reflects what this stack deliberately does and does not do.

The Reporting Summary section describes how the Athena table is built and has a subsection on scan history and duplicates. That last detail is the one to plan for. A security assessment run repeatedly against a changing account produces a history, and a history means you need to know whether a finding in the current run is new, a repeat of an old one, or a resolved issue that has reappeared. The Reporting Summary is where that is described, and it is the section to read before you set a schedule.

The FAQ section exists as well, which is a small sign that the deployment has common failure modes worth documenting.

One thing the README does not do is claim a completeness that Prowler cannot deliver. It describes the reports as generated by Prowler, and the report as a point in time assessment based on AWS best practices, and it points you at Security Hub for continuous enforcement. A reader who takes a single scan as a statement about their account's security will over-read it, and the FAQ and reporting sections are where the tool is honest about what it does and does not cover.

Where the assessment solution is the wrong tool

The first wrong-tool case is continuous monitoring, and the README settles it by pointing at the Security Hub Foundational Security Best Practices standard. A point in time assessment tells you about one moment. If your requirement is to know when something changes, you need the standard, and this solution is the wrong shape for it.

The second is an organisation that cannot take a third-party dependency. The solution runs Prowler, and the README says so directly, that Prowler is not an AWS owned solution, that customers should independently review Prowler before running the solution, and that any dependencies associated with Prowler should be kept up to date. For a regulated environment with a strict software supply chain policy, an open source tool that AWS packages but does not own is a procurement conversation.

The third is a multi-cloud estate. This is an AWS assessment solution with an AWS CloudFormation template, AWS IAM roles and an AWS Organizations delegated administrator path. It will tell you about your AWS account and nothing about the rest of your infrastructure.

The fourth is a team that wants remediation rather than findings. Nothing in the README describes automated remediation or ticket creation. The output is a report, and turning a report into fixed infrastructure is work your team still owns.

The fifth is a scan you need to run once and keep. The pin on the Prowler version exists so that an upstream change cannot break a scan without warning, which is sensible for a reproducible assessment and wrong for a tool you want to track upstream fixes in. The README tells you exactly how to move the pin, and that edit is the maintenance cost you are signing up for.

One practical constraint is worth flagging even though the README does not spell it out. The reports are delivered to an S3 bucket, and those reports describe the weaknesses in your account. The bucket is created by the template, which means the retention and access settings are part of the deployment you are accepting rather than part of what you chose.

Editorial conclusion

The AWS Self-Service Security Assessment Solution fits a security team that needs a documented point in time assessment of an account or a set of accounts, deploys into its own AWS account, and can live with a pinned Prowler version. It is the wrong choice for continuous monitoring, since the README points at the Security Hub Foundational Security Best Practices standard for that, and the wrong choice for an organisation that has to run the scan without Prowler in its dependency set. Before deploying, read the CloudFormation templates in the repository, pin the Prowler version deliberately in 2-sat2-codebuild-prowler.yaml, and confirm the S3 bucket settings fit your data handling rules before the first scan writes findings there.

Frequently asked questions

Official sources

1. awslabs/aws-security-assessment-solution on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases