Application Pipeline Proposal

Every line of code reaches production through the same secure track.

A GitFlow branching model wired into GitHub, where each branch event triggers the right checks. Security gates aren't a final step — they sit between every stage, and code only moves forward when it clears them. Pick a branch below to watch the path light up.

Branching: GitFlow CI/CD + Deploy: GitHub Actions Approvals: GitHub Environments SAST: Checkmarx DAST: Acunetix SCA + Images: Prisma Cloud Scope: App-side only

The pipeline, branch by branch

In GitFlow, different branches do different jobs. A feature branch is a draft; main is what customers run. So they don't deserve the same pipeline. Choose a branch event — the track redraws to show exactly what runs and where the gates are.

How the branches connect

The same model from nvie's "successful Git branching model." Work flows up through develop and a hardened release branch into main; urgent hotfix branches cut straight from main and merge back everywhere.

feature/* — build a change off develop develop — integration of all features release/* — harden & stage a candidate main — production, tagged releases hotfix/* — urgent prod fix off main

The three scanners, in plain terms

Each tool looks for a different class of problem, at a different moment in the journey.

SAST · reads the code

Checkmarx

Static Application Security Testing

Reads your source code without running it — like a proofreader catching unsafe patterns (SQL injection, hard-coded secrets, weak crypto) before they ever ship.

Runs at: every pull request, on the feature branch

DAST · attacks the running app

Acunetix

Dynamic Application Security Testing

Probes the live, deployed application the way an attacker would — sending real requests to find flaws that only appear when the app is actually running.

Runs at: after deploy to dev & staging

SCA + Image scanning

Prisma Cloud

Software Composition Analysis · Checkov

Checks the third-party libraries you depend on and the container image you ship for known vulnerabilities, before the image is allowed near a cluster.

Runs at: dependency install & image build

Controls that are always on

Beyond the named scanners, these guardrails apply to every branch and can't be switched off for convenience — including on a hotfix.

🔒

Branch protectionmain, develop and release require reviews, green checks, signed commits, linear history — no direct or force pushes.

🕵️

Secret scanningGitleaks runs pre-commit and in CI; GitHub push protection blocks credentials from ever entering history.

✍️

Image signingEvery image is signed with Cosign and an SBOM is attached. EKS admission rejects any unsigned or unscanned image.

🎫

All in GitHub, keylessBuild, scan, approve and deploy all run in GitHub Actions. Actions assumes short-lived AWS roles via OIDC — no long-lived keys; pods use IRSA with least privilege.

🗝️

Secrets managementAurora & Mongo Atlas credentials live in AWS Secrets Manager, pulled at runtime via External Secrets — never in the repo.

📑

Evidence captureEach gate writes a signed result to an audit store, building the trail InfoSec and VAPT sign-off need.

Where it lands

The pipeline's output is a signed image promoted by digest through environments — never rebuilt for production. Infrastructure and landing zone are out of scope here; this is the app's destination.

Amazon ECR

Image registry

Stores signed, scanned images. Scan-on-push and immutable tags; only clean digests are promotable.

Amazon EKS

Runtime

Restricted Pod Security, network policies, non-root read-only pods. GitHub Actions performs a guarded Helm rollout and gates on health.

Aurora (RDS)

Relational data

Private subnets, TLS enforced, IAM auth and rotated secrets. No public endpoint.

MongoDB Atlas

Document data

Reached over PrivateLink, x509/SCRAM auth, IP access list, encryption at rest.