Hardening DevSecOps Pipelines for Australian SMBs: SAST, SCA and Secret Scanning Without Alert Fatigue

Recent supply-chain incidents in March 2026 were another reminder that pipelines are now a primary attack path. If your build runners can access secrets, cloud accounts or deployment tokens, your pipeline is part of your production attack surface.

Why pipeline hardening matters now

A lot of SMB teams still treat CI as a convenience layer. That is outdated. Modern pipelines compile code, pull dependencies, run third-party actions, scan containers, sign artefacts and deploy to production. If an attacker compromises that path, they often inherit your trust relationships as well.​‌‌​‌​​​‍​‌‌​​​​‌‍​‌‌‌​​‌​‍​‌‌​​‌​​‍​‌‌​​‌​‌‍​‌‌​‌‌‌​‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​‌‌​​‌‌‌‍​​‌​‌‌​‌‍​‌‌​​‌​​‍​‌‌​​‌​‌‍​‌‌‌​‌‌​‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌​‌‌‌‌‍​‌‌‌​​​​‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​‌‌‌​​​​‍​‌‌​‌​​‌‍​‌‌‌​​​​‍​‌‌​​‌​‌‍​‌‌​‌‌​​‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​‌‌​​‌​‌‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​​​‌‍​‌‌‌​​‌‌‍​‌‌‌​‌​​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​​‌‌‍​‌‌​​​​‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​​‌​‍​‌‌​​‌​‌‍​‌‌‌​‌​​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​​‌‌‍​‌‌​​​​‌‍​‌‌​‌‌‌​‍​‌‌​‌‌‌​‍​‌‌​‌

​​‌‍​‌‌​‌‌‌​‍​‌‌​​‌‌‌‍​​‌​‌‌​‌‍​‌‌​​​​‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌‌‍​‌‌‌​‌​​‍​‌‌‌​​‌​‍​‌‌​​​​‌‍​‌‌​‌‌​​‍​‌‌​‌​​‌‍​‌‌​​​​‌‍​‌‌​‌‌‌​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​‌‌​‌‍​‌‌​​​‌​‍​‌‌‌​​‌‌

The practical lesson from the recent GitHub Actions, PyPI and npm incidents is simple: don’t trust a single scanner, and don’t let any one control carry the whole burden. SAST finds insecure code patterns. SCA finds vulnerable or risky dependencies. Secret scanning catches exposed credentials before they become an incident. Each covers a different failure mode.

For Australian technical leads, the goal is not “maximum scanning everywhere”. It is controlled, layered enforcement that catches high-risk issues early without training developers to ignore alerts.

Build the pipeline in layers, not as one giant gate

Start with three layers.

1. SAST for your own code. Semgrep is fast and easy to tune, which makes it ideal for pull requests. CodeQL is slower but deeper, so it works well for scheduled analysis and protected branches.
2. SCA for dependencies and images. OSV-Scanner is lightweight and good for open ecosystems. Trivy covers filesystems, lockfiles and containers. Snyk is useful where you want richer prioritisation and fix guidance.
3. Secret scanning for obvious and accidental leaks. Gitleaks is a solid pre-merge gate. TruffleHog is useful for deeper entropy and history checks. GitHub secret scanning adds platform-native detection if you use GitHub Advanced Security.

A clean GitHub Actions pattern looks like this:

name: security
on:
  pull_request:
  push:
    branches: [main]

jobs:
  sast:
    runs-on: ubuntu-latest
    permissions: { contents: read }
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: p/owasp-top-ten
  sca:
    runs-on: ubuntu-latest
    permissions: { contents: read }
    steps:
      - uses: actions/checkout@v4
      - uses: aquasecurity/[email protected]
        with:
          scan-type: fs
          ignore-unfixed: true
          severity: HIGH,CRITICAL
  secrets:
    runs-on: ubuntu-latest
    permissions: { contents: read }
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - uses: gitleaks/gitleaks-action@v2

For GitLab CI, keep the same logic:

stages: [test, security]

semgrep:
  stage: security
  image: returntocorp/semgrep
  script:
    - semgrep ci

osv_scan:
  stage: security
  image: ghcr.io/google/osv-scanner:latest
  script:
    - osv-scanner scan --lockfile=requirements.txt

gitleaks:
  stage: security
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --no-git

One important hardening step: pin actions and images to immutable versions or commit SHAs wherever possible. That is one of the fastest ways to reduce supply-chain risk.

Fail the build only for what is truly urgent

Most alert fatigue is self-inflicted. Teams wire every finding to a hard fail, then spend the next month creating bypasses.

A better pattern is:

• Fail the build:
  • verified secrets
  • critical vulnerabilities in internet-facing services
  • high-confidence SAST findings in changed code
  • malicious or unapproved package sources
• Advisory only:
  • medium or low CVEs
  • vulnerabilities with no reachable exploit path
  • legacy code findings outside the current diff
  • container image issues with no fix available yet

In practice, that means Semgrep on pull requests should focus on changed files and high-confidence rules. CodeQL can run nightly or on main and create triaged tickets instead of blocking every branch. Trivy and OSV-Scanner should fail only on HIGH or CRITICAL issues affecting production paths. Gitleaks should almost always be fail-fast because a real secret in Git is not a cosmetic defect.

This is where many SMBs get it wrong: they try to use one severity threshold for every repo. Use different policies for customer-facing apps, internal scripts and experimental projects.

Reduce noise with ownership, baselines and policy

Tooling is only half the design. The other half is governance.

First, baseline existing debt. If you enable every scanner on a mature repo and block on all historical findings, delivery stops. Capture the current state, then fail only on new issues introduced after the baseline date.

Second, map scanners to owners. Platform teams own pipeline controls. Application teams own code findings. Dependency issues should route to the service owner, not to a generic shared inbox.

Third, keep permissions minimal. Your security jobs should not have deployment rights. Your scanners should not inherit more secrets than they need. If a scanning job is compromised, its blast radius should be small.

SLSA Level 1 quick wins for SMB teams

You do not need a massive rebuild to get value from SLSA Level 1 practices.

Quick wins:

• use a hosted CI system with version-controlled build definitions
• keep build steps in Git, not in undocumented click-ops
• generate basic provenance or artefact metadata where your platform supports it
• pin third-party actions, containers and package registries
• separate build, scan and deploy permissions
• protect main branches and require pull request review

These changes improve traceability straight away. They also make later moves toward signed artefacts and stronger provenance much easier.

FAQ

Conclusion

Pipeline hardening works best when it is layered, opinionated and realistic. Use Semgrep and CodeQL for code risk, OSV-Scanner, Trivy or Snyk for dependency risk, and Gitleaks, TruffleHog plus platform-native secret scanning for credential exposure. Then tune enforcement so only the findings that matter most actually block delivery.

If your team wants a practical rollout plan, start with pinned actions, minimal runner permissions, baseline existing findings and hard-fail only on secrets and critical exploitable issues. Visit consult.lil.business for a free cybersecurity assessment.

References

1. ACSC Essential Eight
2. NIST Secure Software Development Framework (SSDF) SP 800-218
3. SLSA Framework
4. GitHub Docs: About code scanning with CodeQL
5. GitHub Docs: About secret scanning