Interview with DevSecOps: Automating security in CI/CD 2025
How security is being redefined in the DevSecOps context
The dovetailing of security with development and operational processes is at a significant turning point in 2025. With the "DevSecOps" concept, the industry is going beyond simply adding security to the classic DevOps pipeline. It creates the basis for teams to consider security aspects right from the start - integrated into every step, not as an afterthought and not as an external element. This transforms security from a parallel discipline to a central component of daily work. How can this new understanding be implemented in everyday DevSecOps work? What hurdles arise during implementation and what automation technologies are companies currently using?
In dialogue: experiences from a DevSecOps team
To shed light on current experiences, I interviewed Julia M., who works as a senior DevSecOps engineer at an international SaaS provider. She explains: "In the past, security was often just an afterthought. Today, we start directly with threat modelling, coordinate risk assessments with product owners and anchor continuous security checks in the process right from the first commit. This has a noticeable effect on team dynamics and productivity." According to Julia, in classically structured CI/CD pipelines, many errors remain undetected for a long time, which makes troubleshooting more time-consuming. With more integrated security checks, vulnerabilities are recognised at an early stage of development, which shortens release cycles and improves code quality.
The daily development process shows that tools for static analyses such as SonarQube or Semgrep run automatically in the background as soon as a pull request is created, and their results flow directly into the code reviews. This is supplemented by dynamic testing mechanisms - such as Dynamic Application Security Testing (DAST) or container-based vulnerability scanners - even before components go into staging or production. Here, security is firmly linked to automation and is no longer a downstream process.
Automation of security in modern CI/CD pipelines
The technical implementation requires strategic decisions to be made. Which scanners, frameworks and platform services will be the focus in 2025? In addition to established solutions such as Trivy for container scans or OWASP ZAP for web applications, the use of cloud-native security offerings is becoming increasingly established. Julia describes her team's approach as follows: "In multicloud environments, we specifically combine open source tools with managed security services from the respective providers. This is crucial for flexibility and scalability, especially when it comes to regulatory requirements."
A practical example: various security jobs are directly embedded in a GitLab CI pipeline. The code checkout is followed by a container scan with Trivy, then a static check via Semgrep and a dependency scan using OWASP Dependency Check. Only after all tests have been passed is the artefact passed on within the pipeline - for further integration or to Canary releases, for example. In this way, security becomes a seamless part of the software supply chain without unnecessarily blocking processes. One of the best practices is to configure security-relevant checks according to the "fail-fast" principle in order to recognise potential risks at an early stage and enable short feedback loops.
# Example for GitLab CI/CD pipeline section with security jobs stages: - test - security - deploy security_sast: stage: security script: - semgrep --config auto allow_failure: false security_dependency: stage: security script: - dependency-check.sh allow_failure: falseAutomation reduces manual effort, but is not a sure-fire success. It requires clearly defined guidelines and continuous monitoring. Failure to maintain policies or misconfigurations can easily lead to a flood of security alerts that significantly delay the CI/CD process.
Cultural change through DevSecOps: responsibility and collaboration
Technical automation goes hand in hand with a change in team culture. Security often remains an isolated area of responsibility for the "InfoSec" department at the beginning. Progressive organisations, on the other hand, rely on decentralisation of expertise and shared responsibility for security. Julia reports: "We establish so-called security champions for each development team and create regular formats for dialogue. This often makes it possible to visualise risks even before the first code commit."
Structured measures are required to create a shared security awareness. Examples include pair programming sessions focussing on security, internal capture-the-flag events or fixed lessons-learned formats. Companies that integrate targeted security training into their onboarding and further training programmes build more competent teams in the long term. This puts prevention and continuous optimisation more in the spotlight than mere compliance checklists.
Typical pitfalls and lessons learnt
A common stumbling block is overestimating automation and tooling. Many teams implement a large number of specialised scanners, but do not orchestrate them holistically. This results in inconsistent reports or incomplete coverage of vulnerabilities. Julia therefore recommends: "A limited but consistent use of tools usually achieves a greater effect. Developers should also be actively involved in security processes and provided with their own channels for feedback and enquiries." Successful teams ensure that security reports are comprehensible, prioritised and processed in day-to-day business - for example, directly in the Git repository.
Dealing with false alarms also remains a constant task. Policies that are too restrictive can block deployments, while settings that are too generous allow vulnerabilities to pass through. Balancing these processes requires regular checks and adjustments. Julia reports on time boxes and fixed DevSecOps review dates, with which teams continuously work on the optimal settings for their security jobs and also treat them as part of their technical debt.
Specific recommendations for an effective DevSecOps launch
IT managers who want to integrate security into their CI/CD processes in a timely manner are faced with several tactical steps. The first step is to systematically review their own software supply chain: Which systems and applications are particularly worth protecting? Where are there real attack surfaces, for example through external components or stored secrets? This is where well thought-out threat modelling pays off, supplemented by a careful inventory of all assets. Only then is it advisable to select automation tools that can be integrated into existing build, test and release processes without media discontinuity.
A step-by-step start makes sense: begin with a few but effective scans - for example, static code analyses, dependency checks and container scans as a foundation. Further test procedures such as dynamic testing or runtime monitoring can be added as required. Comprehensive documentation and regular feedback cycles within the team help with decision-making. Many organisations now combine open source and commercial solutions in order to achieve a good balance between investment and benefit.
Conclusion: DevSecOps as the foundation of modern software development
DevSecOps is already a structurally defining component of modern software development. By consistently integrating automated security and establishing shared responsibility across team boundaries, companies are gaining a solid head start. It remains crucial to drive automation and cultural change in equal measure and to select the tool landscape in line with the overall strategy. The most effective security concepts are created where business, development and security expertise work together. The outlook shows that the increasing use of AI-based analysis tools will further increase precision in the detection and defence of vulnerabilities. DevSecOps is thus developing in a hybrid, highly automated and yet deeply collaborative direction.
