Cloud storage problems often look simple from the outside. A customer clicks a page, an image does not load, and the browser returns an AccessDenied error. But behind that small failure is a bigger engineering lesson: public access, identity permissions, deployment automation, security scanning, and observability all have to work together.

That is the core idea behind the CloudMart Secure Web Assets Pipeline project.

This project started from a beginner cloud troubleshooting scenario: CloudMart, a fast-growing e-commerce startup, hosts website files and product images in Amazon S3. Customers are beginning to report that product images are broken. The immediate issue is S3 public access configuration, but the deeper issue is operational maturity. If the fix depends on manually navigating through the AWS Console, the same problem may recur later.

So instead of treating the lab as a one-time console fix, I rebuilt it as a DevSecOps project using AWS CloudFormation, GitHub Actions, Snyk, Checkov, cfn-lint, endpoint validation, and observability planning.

The goal was not just to make the website load. The goal was to build a repeatable, secure, auditable deployment pipeline.

The Business Problem

CloudMart uses Amazon S3 to host static website files and product images because S3 is durable, low-cost, and easy to scale. That is a reasonable architecture for public website assets.

The problem appears when customers cannot load product images. For an e-commerce company, broken images are not just a technical inconvenience. They affect customer confidence, conversion rates, and revenue.

The original symptom is simple:

403 Forbidden
AccessDenied

But the likely causes include:

• S3 Block Public Access is still enabled.

• The bucket policy does not allow the public s3:GetObject access.

• Website assets were uploaded with the wrong permissions.

• A developer changed the settings manually.

• There is no automated test confirming that assets load after deployment.

• There is no security gate confirming that public access is limited to read-only website content.

The project, therefore, reframes the issue from “fix this bucket” to “build a secure deployment process that prevents the issue from coming back.”

Project Objective

The objective of the CloudMart Secure Web Assets Pipeline is to build an automated AWS deployment system that:

1. Provisions an S3 static website environment using CloudFormation.

2. Deploys website assets through GitHub Actions.

3. Validates CloudFormation before deployment.

4. Scans infrastructure code for security issues.

5. Documents intentional security exceptions.

6. Confirms the website and product image return HTTP 200.

7. Produces evidence that can be used in a portfolio, audit review, or interview.

This turns the original S3 permissions lab into a stronger cloud engineering project by demonstrating not only AWS fundamentals but also infrastructure-as-code, CI/CD, DevSecOps controls, and operational validation.

Architecture Overview

The architecture is intentionally simple, but professional.

Developer
   |
   | git push
   v
GitHub Repository
   |
   v
GitHub Actions Pipeline
   |
   |-- YAML validation
   |-- CloudFormation validation
   |-- cfn-lint
   |-- Checkov IaC scan
   |-- Snyk IaC scan
   |-- CloudFormation deployment
   |-- S3 asset sync
   |-- Endpoint validation
   v
AWS CloudFormation
   |
   v
Amazon S3 Static Website Bucket
   |
   v
CloudMart Website Endpoint
   |
   v
Customers load website files and product images

The deployment pipeline becomes the control plane. Engineers no longer need to adjust the bucket in the AWS Console manually. Instead, the desired configuration lives in source control.

Source Code Structure

The project repository is organized like this:

cloudmart-secure-web-assets/
├── .github/workflows/deploy.yml
├── infra/cloudmart-static-site.yml
├── website/index.html
├── website/error.html
├── website/images/sample-product.svg
├── scripts/validate-site.sh
├── docs/project-brief.md
├── docs/security-exceptions.md
├── docs/validation-report-template.md
├── docs/metrics-plan.md
├── .gitignore
├── .yamllint.yml
└── README.md

Each folder has a clear purpose.

The infra/ folder contains the CloudFormation template. The website/ folder contains the deployable static website files. The .github/workflows/ folder contains the CI/CD workflow. The scripts/ folder contains post-deployment validation logic. The docs/ folder contains project evidence, security exceptions, metrics planning, and reporting templates.

That structure matters because a clean repository makes the project easier to review, maintain, and explain in an interview.

CloudFormation infrastructure verification from the AWS Console.

CloudFormation Infrastructure

The CloudFormation template provisions the core AWS resources:

• S3 bucket for static website hosting

• Static website configuration with index.html and error.html

• S3 bucket policy for public read access

• Server-side encryption

• Versioning

• Public access block configuration

• CloudWatch log group for deployment audit evidence

The most important design choice is the bucket policy.

Because this is an S3 static website endpoint, public users need read access to website files. However, that does not mean the bucket should be fully public. The public permission is scoped to only one action:

{
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::bucket-name/*"
}

The project does not allow public uploads, deletions, bucket listings, permission changes, or ACL changes.

This distinction is important. A public static website bucket is not automatically a bad design. The question is whether public access is intentional, limited, documented, and validated.

Website information from the S3 bucket

GitHub Actions CI/CD Pipeline

The GitHub Actions workflow automates the deployment lifecycle.

On push to mainthe pipeline:

1. Checks out the repository.

2. Installs validation tools.

3. Runs YAML validation.

4. Validates the CloudFormation template.

5. Runs cfn-lint.

6. Runs Checkov.

7. Runs Snyk IaC scanning.

8. Deploys the CloudFormation stack.

9. Reads the stack outputs.

10. Syncs website files to S3.

11. Runs endpoint validation.

12. Uploads a validation report artifact.

This pipeline replaces manual deployment with a repeatable process.

A strong cloud project should not end at “I created a bucket.” It should show how infrastructure changes are reviewed, scanned, deployed, and verified.

GitHub Actions CI/CD Pipeline verification

DevSecOps Security Gates

Security was added directly into the CI/CD process. The pipeline includes several gates.

Gate 1: YAML Validation

YAML validation catches formatting mistakes before the workflow or infrastructure deployment fails unexpectedly.

Gate 2: CloudFormation Validation

AWS CloudFormation validation checks whether the template is structurally valid before deployment.

Gate 3: cfn-lint

cfn-lint checks resource properties, references, and template correctness. It helps catch AWS-specific mistakes before deployment.

Gate 4: Checkov IaC Scan

Checkov scans the CloudFormation template for security misconfigurations. It helps identify risky patterns in infrastructure as code.

Gate 5: Snyk IaC Scan

Snyk adds another DevSecOps layer by scanning infrastructure code for security risks. In this project, Snyk detects that the S3 bucket has public-policy controls disabled. That finding is expected for this specific use case because S3 static website hosting requires public read access.

The important part is not pretending the finding does not exist. The important part is documenting the exception and controlling it.

Gate 6: Post-Deployment Endpoint Validation

The pipeline runs a shell script that checks:

• Website root URL

• index.html

• Sample product image

Each must return HTTP 200.

This validates the business outcome: customers can load the website and product images.

Security Exception: Public S3 Website Access

The project includes a documented security exception for public read access.

The exception states that public s3:GetObject access is allowed only because the bucket hosts public static website assets. The controls are intentionally narrow:

• Public reading is allowed.

• Public upload is denied.

• Public delete is denied.

• Public listing is not granted.

• Public ACLs are blocked.

• Insecure transport is denied.

• Infrastructure changes are managed through CloudFormation.

• CI/CD security scans run before deployment.

This is exactly the kind of documentation that separates a basic lab from a consultant-style project.

Security work is not always about eliminating every warning. Sometimes it is about understanding risk, documenting exceptions, and proving that compensating controls are in place.

Observability and Metrics

The project also includes an observability and metrics plan.

The two main observability sources are:

• GitHub Actions for CI/CD execution evidence

• Datadog for synthetic uptime monitoring and dashboards

Recommended Datadog checks include:

• Homepage uptime

• Product image uptime

• HTTP response status

• Response time

• Deployment success/failure trends

• Security scan trends

The metrics plan uses DevOps and DevSecOps measurements, such as:

These metrics strengthen the project by connecting engineering work to operational performance.

Pipeline Issues and Resolutions

During maintenance, several real CI/CD issues were identified and resolved. These are valuable because they show practical troubleshooting, not just a clean final-state demo.

Issue 1: Snyk High Findings Reported as Failures

The pipeline reported Snyk findings for:

SNYK-CC-TF-96
SNYK-CC-TF-98

These findings relate to S3 public policy controls being disabled. At first glance, they look like high-severity failures. However, in this project, they are documented exceptions because the S3 bucket intentionally hosts a public static website.

The confusion stemmed from differences among Snyk's display surfaces. The Snyk dashboard and bare CLI output show human-readable high findings, but the CI gate uses JSON output and post-processing logic to compare findings against the repository allowlist.

The resolution was to document how to read Snyk output and update the local test script to run the same Snyk gate logic as CI. The authoritative CI result showed two high findings, both matched to documented exceptions, and the security scan passed.

Failures noted in Synk before corrections are reported as failures

After updating Sync Output

Issue 2: Empty S3 Bucket Output Caused aws s3 sync s3:///

Another failure occurred when the pipeline attempted to run:

aws s3 sync website/ s3:///

The bucket name was empty because the CloudFormation stack output could not be read. The underlying stack was stuck ROLLBACK_COMPLETE from a failed first-time create.

The resolution was to strengthen the Read stack outputs step with set -euo pipefail and explicit error handling. Now the pipeline fails early with a useful error message if required outputs are missing.

This is an important improvement because the original failure appeared during aws s3 sync, but the real problem was the CloudFormation stack state.

Issue 3: GitHub Actions Node.js 20 Deprecation Warning

The pipeline was green but showed a runner warning that aws-actions/configure-aws-credentials@v5 was still running on Node.js 20.

The fix was to upgrade the workflow to aws-actions/configure-aws-credentials@v6use Node 24. After the update, the deployment completed without any Node.js 20 deprecation annotations.

The lesson is simple: do not assume every latest major version of a GitHub Action has upgraded its runtime. Each action maintainer ships runtime upgrades on a different schedule.

What This Project Proves

This project proves several practical cloud engineering skills:

• S3 static website hosting

• S3 bucket policy design

• Public access troubleshooting

• CloudFormation infrastructure as code

• GitHub Actions CI/CD

• DevSecOps security scanning

• Security exception documentation

• Endpoint validation

• Observability planning

• CI/CD troubleshooting

• Audit-ready documentation

The strongest part of the project is that it does not stop at deployment. It includes validation, security review, metrics, and maintenance lessons.

That is what real engineering work looks like.

Conclusion

The CloudMart Secure Web Assets Pipeline is more than an S3 lab. It is a complete cloud engineering project that connects business impact, infrastructure automation, security controls, observability, and troubleshooting.

The original issue was broken product images. The final result is a repeatable DevSecOps deployment system that can detect errors, document risks, validate outcomes, and support future production upgrades, such as CloudFront, Origin Access Control, AWS WAF, and GitHub OIDC.

That is the difference between fixing a cloud problem once and designing a system that prevents it from happening again. Please take the time to review the GitHub repository: https://github.com/mdixon47/aws-cloudmart-secure-web-assets