What is it?
A GitLab DevSecOps foundation is a delivery operating model in which development, security and operations share responsibility for delivering software safely, using GitLab as the connected platform for source control, merge requests, CI/CD, security signals and release information.
Software teams rarely struggle with DevSecOps because they lack another security scanner. They struggle because development, security and operations make decisions in different systems, apply controls at different points and often cannot reconstruct the complete path a change followed into production. GitLab reduces that fragmentation by bringing these capabilities into a connected workflow.
Use this approach when establishing or improving DevSecOps on GitLab, consolidating from fragmented toolchains, or when audit and compliance teams need evidence that faster delivery has not weakened controls.
Why it matters
Risks
- Without clear ownership of groups, runners, templates and security exceptions, inconsistent controls create audit gaps that surface under regulatory scrutiny.
- A poorly isolated runner can create a route from CI/CD into systems that were otherwise carefully protected.
- Security gates that generate constant noise are eventually ignored, leaving genuine findings unaddressed.
Costs
- Fragmented tooling forces development, security and operations to maintain controls in disconnected procedures, multiplying coordination cost.
- Copying large .gitlab-ci.yml files into every repository is not sustainable standardisation and creates maintenance overhead that scales with team count.
- Reconstructing release evidence from screenshots, emails and spreadsheets weeks after deployment consumes engineering time that could deliver value.
Operational impact
- If every change requires the same heavyweight approval process, teams eventually look for ways around it, creating shadow processes.
- Pipeline inconsistency means teams cannot predict which checks run, which credentials are used or how failures should be investigated.
- Without quality gates beyond vulnerability scanning, functionally incorrect or unreliable software can pass security gates while remaining unsafe to release.
Strategic impact
- Competitors that consolidate toolchains and automate delivery controls ship features faster and reduce compliance preparation time.
- Finance and risk teams block faster release cadence when they cannot see evidence that controls remain intact.
- Organisations without a paved road create bottlenecks when centralising every decision, or inconsistent controls when delegating everything.
How to build a GitLab DevSecOps foundation
Ownership before automation
- Define platform ownership covering the GitLab service, common templates, runners, integrations and platform-level policies.
- Application ownership should remain with the team responsible for the software and its delivery path.
- Security ownership should define mandatory controls, risk acceptance and exception processes without turning the security team into the manual approver for every change.
- Operational ownership should make it clear who supports failed pipelines, deployment problems and production incidents.
Merge controls as the centre of change
- Make the merge request a useful decision point where reviewers can understand what is changing, why, which tests ran, which security findings were identified and whether approvals are required.
- Use protected branches, appropriate approval rules and meaningful code ownership to strengthen the process.
- Apply proportionate controls that reflect actual risk rather than a uniform heavyweight process.
Standardised CI/CD without bottlenecks
- GitLab CI/CD components and reusable configurations help platform teams create supported patterns for common build, test, security and deployment activities.
- Standardisation is particularly useful for controls that should not depend on every application team remembering to recreate them.
- Reusable pipelines should not become opaque platform magic. Application teams still need to understand what executes, which credentials are used and how failures should be investigated.
Runner security and boundaries
- Consider whether a workload can use hosted or shared execution, when dedicated or self-managed runners are justified, network access available to a job, credential exposure, workload isolation and whether runner environments are ephemeral.
- This matters particularly when pipelines can deploy infrastructure, access production services or work with sensitive artefacts.
- Self-managed runners need patching, capacity planning, security configuration, observability and lifecycle management.
Security testing where developers can act
- Incorporate GitLab application-security capabilities into the development and CI/CD workflow, including SAST, dependency scanning, container scanning, secret detection and dynamic testing where appropriate.
- Start by establishing visibility and a triage process, then decide which findings should block a merge, which need additional approval and how false positives are handled.
- A useful security control needs enough signal quality that teams trust it.
Quality engineering in the delivery path
- The delivery path should consider unit testing, integration testing, automated functional testing, API testing, performance testing, security scanning and manual exploratory testing where justified.
- Fast tests should give developers early feedback. More expensive suites can run later or against appropriate test environments.
- The design question is how quickly the team can obtain useful evidence without creating a pipeline so slow that developers avoid it.
Evidence generation during delivery
- A well-designed process can retain information about the requested change, code review, automated tests, security scans, approvals, pipeline execution, artefacts and deployment activity.
- Evidence supports engineering reviews, customer assurance and compliance processes without claiming to prove compliance by itself.
- The exact evidence required depends on the organisation obligations, but an integrated workflow provides a more defensible technical history than manual reconstruction.
Common mistakes
Switching on every available feature and hoping a coherent process emerges
Consequence: Teams lack a deliberate operating model, resulting in inconsistent controls and processes that no single person can explain to an auditor.
Avoidance: Start with the delivery system you want teams to follow. Configure the technology around that operating model rather than enabling features indiscriminately.
No runner policy or trust boundary definition
Consequence: A poorly isolated runner becomes a route from CI/CD into production systems that were otherwise carefully protected.
Avoidance: Treat runner design as security infrastructure. Document network access, credential exposure, workload isolation and whether environments are ephemeral.
Security gates that generate noise rather than signal
Consequence: Teams learn to ignore gates that constantly fire, meaning genuine findings are missed and the control provides no real protection.
Avoidance: Define a transparent exception and remediation process. Separate existing vulnerability debt from new risk and ensure signal quality is high enough that teams trust the gate.
Best practices
- Group and project ownership is documented.
- Access is based on role and need rather than convenience.
- Protected branches and merge rules reflect application risk.
- Common CI/CD patterns are reusable and maintained.
- Runner trust boundaries are understood.
- Credentials are not embedded in pipeline configuration.
- Security scanning has a defined triage process.
- Quality gates include more than vulnerability scanning.
- Exceptions have owners and expiry conditions.
- Environment promotion is controlled.
- Deployment and rollback responsibilities are known.
- Release evidence can be reconstructed without manual archaeology.
- Teams know who supports the delivery platform.
- The platform is reviewed as engineering practices change.
Tools and processes
- GitLab CI/CD components for reusable pipeline patterns
- Protected branches and merge request approval policies
- GitLab-hosted runners and self-managed runners with defined trust boundaries
- SAST, dependency scanning, container scanning, secret detection
- Environment promotion through controlled deployment pipelines
How to get started
- Map engineering teams, products, services, shared components, infrastructure repositories, deployment environments, data sensitivity and regulatory boundaries.
- Define ownership at platform, application, security and operational levels.
- Design group and project structure based on how software is actually built and operated rather than mirroring an organisation chart.
- Implement protected branches and merge request controls proportionate to application risk.
- Create reusable CI/CD components for common build, test, security and deployment activities.
- Document runner trust boundaries, network access and credential exposure for each workload type.
- Establish a security triage process that separates existing vulnerability debt from new risk.
- Verify that release evidence can be reconstructed without manual archaeology.
If the immediate problem is audit gaps, start with ownership documentation and evidence generation. If the blocker is pipeline inconsistency, start with reusable CI/CD components and runner policy. Both paths converge on the same governed delivery system.
How KineticSkunk helps
KineticSkunk works with engineering and technology teams to connect GitLab delivery controls to the cloud platforms that applications actually run on, including group and project design, CI/CD standards, runner architecture, security and quality controls, migration, environment promotion and operational handover.
The objective is to create a delivery path that engineering teams can use repeatedly, security teams can understand and platform teams can operate. For organisations already using GitLab, this can begin with an assessment of the existing estate rather than a redesign.
If you are establishing DevSecOps with GitLab, take the DevSecOps Maturity Assessment or read the Jenkins to GitLab migration case study for a practical view of the migration problem.
Frequently asked questions
GitLab provides capabilities that can support DevSecOps across source control, merge requests, CI/CD, security testing and software delivery. DevSecOps still requires an operating model covering ownership, risk, quality, security and production delivery.
Start with identity, group and project structure, ownership, merge rules, runner boundaries and a repeatable CI/CD foundation. Add security and quality controls to that delivery path rather than treating them as separate projects.
Not necessarily. Blocking policy should reflect severity, exploitability, application context and the organisation risk requirements. Define a transparent exception and remediation process rather than creating gates that teams learn to bypass.
No. Automated scanning is one part of DevSecOps. Secure delivery also depends on access control, reviews, secrets management, software quality, runner security, deployment governance, operational practices and appropriate security testing.
Assess the whole delivery system: ownership, permissions, reusable pipelines, runner isolation, testing, security policies, environment promotion, evidence, exceptions and operational support.
