DevSecOps and
CI/CD Security
A report that lands three weeks after the release it describes is an archive, not a control. Trigger assessments from the pipeline, fail the build on critical findings, and get the result as an issue against the line that caused it.
Into the pipeline
Testing at the speed of your release cycle
Findings are only useful while the context that produced them is still in someone's head.
01
Trigger assessments from the pipeline
On-demand assessments are triggered from your pipeline through the Lemon API, and builds can be failed on critical findings rather than merely annotated with them.
02
Findings arrive where the work happens
GitHub and GitLab issues are opened against the affected repository with line-level references to the vulnerable code. Jira tickets carry bi-directional status sync — close it in Jira and it closes in Lemon.
03
Change and incident records, automatically
ServiceNow change records and incident tickets are created from verified findings, so the audit trail exists without anybody transcribing it.
04
Alerts to the channel that owns the fix
Slack alerts on new findings, status changes and engagement milestones, to nominated channels rather than to an inbox.
The pipeline itself
The build system is production access
Anything that can deploy can be used to deploy. IaC and CI/CD review covers the pipeline as an asset in its own right.
Infrastructure as code
Terraform, CloudFormation and Bicep — what the definitions actually provision, not what the plan says they will.
Pipeline definitions
GitHub Actions, GitLab CI and Jenkins pipelines, including what a workflow can be made to run and by whom.
Runner trust
What a build runner can reach, what it holds, and what a compromised job inherits.
Pipeline secrets
Where secrets enter the build, where they end up, and what a log retains after the job finishes.
Container images
Dockerfiles and the image build path, including signing.
Supply chain
Lockfile audit, transitive CVEs, package-source verification, and secret-scanning gaps.
Commercials
A contract shaped like a release cycle
A fixed annual scope agreed in April does not describe what ships in September. The on-demand rate contract sets pre-agreed rates with a minimum utilisation commitment — priced per IP, per application or per man-day — with agreed SLAs and CI/CD integration through the Lemon API.
It exists for variable testing volumes and agile release cycles. Where a programme genuinely is fixed and annual, the annual contract is the cheaper answer and we will say so.
Compare the engagement models →Questions
Frequently asked
Is this a DevSecOps maturity assessment or a transformation programme?
No. This is security testing that runs at the speed of your pipeline, plus review of the pipeline itself. If what you need is an organisational maturity model or a coaching engagement, we are not the right answer and would say so at scoping.
How does the pipeline integration actually work?
Assessments are triggered on demand from your pipeline through the Lemon API, and the build can be failed on critical findings. Findings are pushed back as GitHub or GitLab issues against the affected repository with line-level references, or as Jira tickets with bi-directional status sync.
Does this replace scanning in the pipeline?
It is not a scanner. Scanners are good at pattern matching and run continuously; what they cannot do is business logic, authorisation, or the question of whether a pipeline can be made to build something it should not. Keep the scanner. This covers what it does not reach.
What commercial model suits release cycles rather than projects?
The on-demand rate contract: pre-agreed rates with a minimum utilisation commitment, priced per IP, per application or per man-day, with agreed SLAs and CI/CD integration through the Lemon API. It exists for variable testing volumes and agile release cycles rather than for a fixed annual scope.
How does this relate to secure code review?
IaC and CI/CD review is one of the modules within secure code review, alongside business logic, supply chain, secret management and error handling. This page is the pipeline-facing view of that work plus the integration that puts it into your release process; the code review page covers the language-level depth.
Put testing inside the release, not after it
Scoping starts with your pipeline and your release cadence — not with a questionnaire.
Request a Scoping Call