DevSecOps & secure delivery

A pipeline is both a control point and an attack surface — it holds your credentials and can push code to production. I work both sides of that, matched to how your team already ships.

• SAST

  Static analysis in CI

  Code scanning wired into pull requests and tuned against your codebase, so developers get findings they trust instead of a wall of noise they mute.

• SCA

  Dependencies & supply chain

  Dependency scanning, lockfile hygiene, and protection against dependency confusion and typosquatting — the attack I've published a full guide on.

• SECRETS

  Secret detection

  Pre-commit and pipeline secret scanning, plus history sweeps for the keys already committed, and a rotation path for whatever turns up.

• PIPELINE

  Pipeline hardening

  GitHub Actions workflow injection, over-scoped tokens, unpinned third-party actions, and runners that trust a pull request far more than they should.

• DAST

  Dynamic testing & IaC

  Automated application scanning against staging environments, and infrastructure-as-code checks before a misconfiguration becomes live infrastructure.

• GATES

  Policy & release gates

  Branch protections, required reviews, signed commits, SBOM generation and build-blocking thresholds that are strict where it matters and quiet everywhere else.

Aligned with the OWASP DevSecOps Guideline, OWASP SAMM, NIST SSDF and SLSA.

1. 01

   Pipeline review

   I read your existing workflows, branch rules and permissions, and map where code and credentials flow from a commit to production.

2. 02

   Threat model the pipeline

   Who can trigger a build, what a build can reach, and what a malicious pull request or compromised dependency would get — before adding any tooling.

3. 03

   Wire in the controls

   Scanning, secret detection and supply-chain checks implemented as working pipeline configuration, in report-only mode first so nobody's delivery stops on day one.

4. 04

   Tune, then enforce

   Baseline the existing findings, cut the false positives, agree thresholds with the team, and only then turn the gates on for real.

5. 05

   Handover & developer enablement

   Documentation and a walk-through so your engineers own it — including how to triage a finding and how to request an exception without going around the gate.

• A review of your current pipeline with the gaps ranked by risk
• Working CI/CD configuration implementing the controls, not just recommendations
• Tuned scanning with a triaged baseline instead of thousands of open findings
• A secret-scanning and key-rotation plan for what's already committed
• Documentation and a developer walk-through so the setup survives handover

• OWASP DevSecOps Guideline
• OWASP SAMM
• NIST SSDF (SP 800-218)
• SLSA

At Invygo I integrated security practices into CI/CD workflows on GitHub and built container scanning and vulnerability management with Trivy and Clair, while working across engineering and application security on the same microservices. I've also written the DevSecOps 101 series and a full guide to dependency confusion attacks and their prevention.

What is DevSecOps?

Building security into how software is delivered rather than testing it at the end: scanning and policy checks running automatically on every commit, build and deploy, so problems surface while the code is still fresh in a developer's head and cheap to fix.

Won't security scanning slow our delivery down?

Badly configured, yes — that's the usual reason teams abandon it. I roll controls out in report-only mode, triage the existing backlog into a baseline, cut false positives, and only enforce gates on the classes that genuinely justify blocking a release.

Which tools and platforms do you work with?

Primarily GitHub and GitHub Actions, with SAST, SCA, secret scanning, container scanning (Trivy, Clair) and DAST tooling chosen to fit your stack. The approach transfers to GitLab CI and similar platforms.

Is the CI/CD pipeline itself a target?

Very much so — it holds credentials and can deploy to production. Workflow injection, over-scoped tokens, unpinned third-party actions and over-trusting runners are all part of the assessment, not an afterthought.

Do you just advise, or do you implement it?

I implement it. The deliverable includes working pipeline configuration, tuned tooling and a triaged baseline — then documentation and a walk-through so your team owns it afterwards.

Do you work with companies in Morocco?

Yes. I'm based in Morocco, available on-site across the country and remote for clients anywhere. Documentation can be delivered in English or French.