Case Studies · Last updated June 2026

Case Study: An Organisation-Wide DevSecOps Pipeline Transformation

The Problem

When I took over as DevOps Team Lead at wesionaryTEAM, the organisation managed 10+ concurrent client production environments, each with its own GitHub Actions CI/CD pipelines. None of those pipelines had security checks of any kind. There was no secrets scanning, so a leaked AWS key could sit undetected in commit history. There were no IaC compliance checks, so a Terraform config could open an S3 bucket publicly or grant a wildcard IAM policy and nobody would catch it until it hit production. The security boundary was the developer's memory, not the system.

The organisation was growing, with new client environments coming online every few months, and each one added more surface area. Doing security reviews manually after the fact wasn't scaling, and it was the wrong place to catch things.

Constraints

• 10+ separate client environments, each maintained independently. Any change had to scale across all of them without per-environment customisation.
• Cannot slow down developer velocity: gates had to run in under 2 minutes or they would be bypassed.
• Open-source tooling only, since there was no budget for commercial SAST/DAST platforms.
• Multiple tech stacks (ECS-based, EKS, different app frameworks), so pipeline changes had to be composable across stack differences.

The Approach

1. Secrets scanning in CI and pre-commit

I integrated detect-secrets and truffleHog as two layers: a pre-commit hook catches secrets locally before a push is attempted, and a GitHub Actions step blocks the PR if anything slips through. Both scan full commit history rather than just the diff, so a secret added and then "deleted" in a later commit is still caught.

# .github/workflows/security.yml (simplified)
jobs:
  secrets-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0          # full history scan
      - name: truffleHog scan
        uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified

2. IaC compliance with tflint and OPA/conftest

tflint handles Terraform-level issues: deprecated syntax, missing provider version constraints, undefined variables, and provider-specific rule sets. For policy enforcement (business rules the linter can't express) I introduced OPA conftest with a shared policy library:

• No S3 buckets without server-side encryption and versioning enabled
• No wildcard (*) actions in IAM policies
• All EC2 security groups must have Name and Environment tags
• VPC flow logs required for any new VPC
• RDS instances must have deletion protection and automated backups enabled

These run as a blocking step on every Terraform PR; a plan is never applied without passing both linting and policy checks.

3. IAM least-privilege enforcement

The existing IAM roles across client AWS accounts had accumulated permissions over years of "we'll tighten this later" decisions. I ran an audit using AWS IAM Access Analyzer and CloudTrail-based unused access reports: any permission not exercised in the prior 90 days was removed. Wildcard actions (s3:*, ec2:*) were replaced with specific action lists. Service roles were scope-limited to the specific resources they actually touched.

The IAM permission surface came down by roughly 60% across all accounts, and nothing broke, because I only removed permissions that CloudTrail showed had gone unused for the prior 90 days.

4. Secret management with SOPS + AWS KMS

Plaintext secrets in environment variables and unencrypted CI secret stores are a single breach away from full exposure. I migrated all application secrets to SOPS with AWS KMS encryption: secret files live in the repository, encrypted at rest with a per-environment KMS key. Decryption happens at deploy time inside the CI pipeline using the deployment role's IAM permissions — no human ever has plaintext access to production secrets outside of their own terminal.

# Encrypt a secrets file for the production environment
sops --encrypt --kms arn:aws:kms:ap-northeast-1:123456789:key/... \
  secrets.yaml > secrets.enc.yaml

# In CI: decrypt and inject at deploy time
sops --decrypt secrets.enc.yaml | envsubst > .env

Rollout Strategy

I rolled out gates in phases rather than all at once. Phase 1: secrets scanning only (lowest friction, highest impact). Phase 2: tflint. Phase 3: conftest policies, introduced as warnings for two weeks before becoming blocking. Phase 4: IAM audit and SOPS migration, which required coordinating local tooling updates with developers.

Each phase was applied to one internal project first, stabilized, then propagated to all client environments via a shared reusable GitHub Actions workflow. The gate logic lives in one place; all environments inherit it automatically.

Results

In the first quarter after full rollout: 12+ Terraform misconfigurations blocked before apply, IAM surface area down ~60% with no service disruptions, and secrets scanning catching accidental credential commits before they reach the remote. The change that matters most over time: new client environments inherit every gate automatically when they adopt the shared workflow, so nobody has to remember to add them.

What I'd Do Differently

• Start with two gates maximum. Rolling out five at once caused a brief "just bypass it" spike; a slower rollout, a couple of gates at a time, would have stuck better.
• Invest in fast failure early: secrets scanning needs to run in under 30 seconds. We optimized this late; slow gates get disabled by frustrated developers.
• Add SAST for application code earlier — infrastructure security came first and app-layer scanning was a separate, later effort.