Building a DevSecOps pipeline with Bob
Use an AI development partner to draft, review and harden a CI/CD pipeline with security gates that a platform team can actually approve.
Prompt
Act as a DevSecOps engineer. Review the attached GitLab CI pipeline. Identify missing security controls (dependency scanning, SAST, secret detection, container scanning, signed artifacts, least-privilege runners). Return a revised pipeline plus a table of every change with its risk rationale.
Problem
Most pipelines grow organically. Security controls are added after incidents, inconsistently across repositories, and nobody has time to normalise them by hand.
Scenario
A platform team maintains 40+ service repositories on GitLab. Each has a slightly different pipeline. The goal is one reviewed baseline that teams can adopt incrementally.
Architecture
- Shared pipeline template repository consumed via `include:`
- Stages: build, unit test, SAST, dependency scan, container scan, sign, deploy
- Policy gate before deploy; findings published as job artifacts
Why Bob?
Pipeline hardening is pattern work over large YAML files — exactly the kind of repetitive, context-heavy review where an AI development partner accelerates a human engineer. Bob drafts; the platform team decides.
Prompt
See the prompt block above — copy it and attach your pipeline file.
Bob Workflow
- Analyse the repository and existing pipeline
- Propose a stage plan before writing YAML
- Generate the revised pipeline plus a change table
- Iterate on runner permissions and cache scope
Generated Result
A template pipeline with explicit stages, scoped runner tags, cached dependency installs, and scanning jobs that fail on high severity only — so adoption is not blocked by legacy findings.
Validation
- Run the pipeline against a deliberately vulnerable branch
- Confirm the gate fails and produces readable findings
- Confirm the happy path build time stays within budget
Security
Never let generated pipelines widen permissions. Review every `rules:`, token scope and registry credential by hand before merging.
Lessons Learned
- Ask for a change table, not just YAML — reviews get far faster
- Generated severity thresholds are usually too strict for brownfield repos
- Pin scanner image versions; models tend to emit `latest`
Resources
- Your organisation's pipeline policy
- IBM Bob official documentation