What is it?
Secure software delivery with GitLab DevSecOps means integrating application-security testing into the normal development and CI/CD workflow, supported by appropriate policy, exception management, runner security and evidence generation.
GitLab can place application-security checks close to the code change, but secure delivery needs more than scanners. Teams need trustworthy findings, appropriate approval policy, software-quality testing, controlled exceptions, secure runners and evidence that survives beyond the pipeline.
Use this approach when establishing or improving security testing within GitLab delivery pipelines, when audit or compliance teams need evidence of security controls, or when security gates are generating noise rather than actionable findings.
Why it matters
Risks
- Security gates that generate constant noise are eventually ignored, leaving genuine findings unaddressed.
- A poorly isolated runner can create a route from CI/CD into systems that were otherwise carefully protected.
- Credentials committed to source control create exposure that persists in repository history, logs, artefacts and clones.
Costs
- Security appearing only at release creates expensive late rework because developers discover problems after the most convenient fix point.
- Maintaining security controls in a system disconnected from development means findings lose the context of the change that created them.
- Reconstructing security evidence from manual processes after deployment consumes time that could deliver value.
Operational impact
- Without a transparent exception process, security programmes become brittle when they pretend exceptions do not exist.
- Treating all scanner categories as interchangeable leads to misplaced confidence about what has actually been tested.
- Security testing that displaces software quality means a secure release can still fail customers through functional or performance defects.
Strategic impact
- Organisations that cannot demonstrate security controls integrated into delivery face increased audit preparation time and regulatory scrutiny.
- Competitors that embed security in the development workflow ship securely without the overhead of separate release ceremonies.
- Finance and risk teams block faster release cadence when they cannot see evidence that security controls remain intact.
How to implement secure software delivery with GitLab
Bring security testing into the development workflow
- GitLab supports security testing including SAST, dependency scanning, container scanning, secret detection and DAST.
- These techniques answer different questions and should not be treated as interchangeable.
- Present findings while the developer still has the change context rather than immediately before release.
Put security findings in the merge decision
- The merge request is an effective place to present security findings because the developer and reviewer already have the change context.
- Create policy around risk: severity, exploitability, reachability, existing exceptions, and who is allowed to accept risk.
- GitLab security and approval policies can help enforce parts of this process, but policy configuration still needs human judgement.
Separate scanning from penetration testing
- Automated security scanning provides repeatable controls that can operate frequently.
- Penetration testing involves skilled adversarial assessment that can test attack paths automated scanners do not model.
- A mature assurance strategy decides where continuous automated controls are sufficient and where deeper manual security testing is justified.
Keep software quality alongside security
- A secure release can still fail customers through functional defects, integration failures, data errors and performance regressions.
- Quality engineering should sit alongside security in the delivery model, including unit, integration, functional, performance and security testing.
- The correct mix depends on the system and its risk profile.
Protect the pipeline itself
- Self-managed runners deserve scrutiny around isolation, ephemeral execution, network segmentation, privilege, credential access and patching.
- Do not give every build job broad access to the environment simply because doing so makes deployments easier.
- The runner should receive the minimum access required for its job.
Make exceptions explicit
- A realistic process allows a finding to be accepted temporarily when justified, but requires enough information to make that decision accountable.
- Record the finding, reason, owner, compensating controls, expiry date and remediation plan.
- A permanent undocumented bypass is not an exception process.
Use evidence without overstating compliance
- GitLab can help retain technical evidence about code review, automated checks, approvals and deployments.
- That can materially improve auditability but does not mean GitLab itself makes an organisation compliant.
- Use delivery evidence as one input into compliance and assurance processes.
Common mistakes
Treating all security scanner categories as equivalent assurance
Consequence: Teams develop misplaced confidence about what has been tested, missing entire categories of vulnerability that their scanners do not cover.
Avoidance: Understand what each scanner type can and cannot find. Layer techniques deliberately and include penetration testing where deeper assurance is justified.
Blocking every merge on every finding regardless of severity or context
Consequence: Developers learn to work around gates, creating shadow processes that bypass security entirely.
Avoidance: Define proportionate policy. Separate new risk from existing debt. Allow documented exceptions with accountable owners and review dates.
Ignoring pipeline and runner security while focusing on application scanning
Consequence: A compromised runner or overly permissive job can bypass all the application-security controls that the pipeline is supposed to enforce.
Avoidance: Treat runner design as security infrastructure. Document trust boundaries, credential exposure, isolation and network access.
Best practices
- Security scanning runs close enough to changes to be actionable.
- New findings can be distinguished from existing vulnerability debt.
- Severity is not the only input into risk decisions.
- Exceptions have accountable owners.
- Exceptions have review or expiry conditions.
- Dependency risk is continuously revisited.
- Container images follow an approved build and registry path.
- Secrets are not stored in source or pipeline definitions.
- Runner trust boundaries are documented.
- DAST targets appropriate test environments.
- Penetration testing is used where deeper assurance is required.
- Functional and performance quality remain part of release decisions.
- Security evidence is retained with the delivery record.
Tools and processes
- GitLab SAST, dependency scanning, container scanning, secret detection
- GitLab DAST for dynamic application-security testing
- Security and merge request approval policies
- Protected runners with defined trust boundaries
- Vulnerability management and exception tracking
How to get started
- Enable SAST and dependency scanning on representative repositories to establish visibility into the current finding landscape.
- Separate existing vulnerability debt from new risk introduced by recent changes.
- Define a triage process that considers severity, exploitability and application context, not just scanner output.
- Configure merge request approval policies proportionate to application risk.
- Establish an exception process with accountable owners, compensating controls and review dates.
- Review runner trust boundaries, credential exposure and isolation for CI/CD environments that execute security-sensitive workloads.
- Incorporate quality engineering alongside security so that release decisions consider functional and performance reliability.
If security gates are generating noise that teams ignore, start with signal quality and exception management. If runner security is undefined, address trust boundaries before expanding scanning. Both paths converge on a delivery model where security, quality and evidence work together.
How KineticSkunk helps
KineticSkunk helps organisations put security and quality controls into normal delivery rather than treating them as a separate release ceremony, including GitLab security testing, CI/CD policy, runner and secrets architecture, testing strategy, pipeline standards and evidence aligned with managed AWS and Azure environments.
The objective is a delivery model where security, quality, delivery speed and compliance evidence coexist rather than compete. For teams already using GitLab, this can begin with an assessment of the existing security posture rather than a redesign.
If you are integrating security into GitLab delivery, take the DevSecOps Maturity Assessment or explore Governed Delivery for the broader controls model.
Frequently asked questions
GitLab supports application-security capabilities including SAST, dependency scanning, container scanning, secret detection and DAST, with additional testing capabilities available for appropriate use cases. Exact availability depends on the GitLab configuration and subscription.
No. SAST inspects source code and is useful for early feedback, but secure software delivery also requires dependency, secrets and runtime considerations, secure architecture, appropriate dynamic testing and, where justified, penetration testing.
Critical findings warrant urgent investigation, but risk decisions still require context such as exploitability, affected functionality, compensating controls and whether a trustworthy fix exists. Define policy in advance rather than improvising during a release.
No. GitLab can help implement and evidence technical controls. Compliance depends on the complete set of applicable organisational, technical, contractual and legal requirements.
Vulnerability scanners automatically identify known patterns and weaknesses. Penetration testing uses skilled adversarial techniques to examine how a system can actually be attacked. They are complementary rather than equivalent.
