devopsy.kinsta.cloud

Tag: devsecops

CI/CD Supply Chain Security: Hardening Artifacts, Dependencies, and Delivery Pipelines

Modern CI/CD pipelines have become one of the most attractive attack surfaces in enterprise environments. As organizations push for faster releases, broader automation, and greater reuse of third-party components, the software supply chain has quietly expanded beyond the direct control of any single team. Source code is only one small piece of what ultimately runs in production. Artifacts, dependencies, and delivery pipelines themselves now represent critical trust boundaries, and increasingly, they are where attackers focus.

For practitioners, the challenge is not whether supply chain attacks are real. That question has already been answered. The real question is how to design CI/CD pipelines that move quickly and enforce trust at every handoff point, without turning security into a bottleneck.

Why CI/CD Is a Prime Supply Chain Target

CI/CD systems sit at the intersection of code, credentials, and automation. They routinely pull dependencies from external sources, generate artifacts that move across environments, and often hold privileged access to cloud infrastructure and production systems. A compromise here gives attackers leverage far beyond a single application.

What makes pipeline-level attacks especially dangerous is how quietly they succeed. A malicious dependency, a modified artifact, or an unverified build can move through the pipeline exactly as designed. From the pipeline’s perspective, everything is “green.” From a security perspective, trust has already been broken.

This is why many modern security frameworks emphasize that supply chain defense must extend beyond source code and into the systems that build and deliver it. Guidance such as the Secure Software Development Framework published by the National Institute of Standards and Technology (NIST) reinforces the idea that build integrity, artifact traceability, and controlled delivery are essential parts of secure software development, not optional enhancements.

Securing Dependencies Without Slowing Teams Down

Dependencies remain one of the most common entry points for supply chain compromise. Modern applications rely on large dependency graphs, often pulled automatically during builds with minimal validation beyond version pinning.

For practitioners, the goal is not to eliminate third-party dependencies. That is unrealistic. The goal is to establish clear rules around how dependencies enter the pipeline and how consistently they are resolved. Approved sources, deterministic builds, and visibility into dependency metadata all play a role in maintaining trust.

Repeatability is especially critical. If a pipeline cannot reliably reproduce the same dependency set across builds, it becomes difficult to detect tampering or drift. Reproducible builds are not just a reliability concern; they are a foundational security requirement for defending the software supply chain.

Artifacts as First-Class Security Assets

Once code and dependencies are compiled, packaged, or containerized, the resulting artifact becomes the unit of delivery. This is where many pipelines quietly lose security context. Artifacts are often treated as disposable outputs rather than high-value assets.

In practice, artifacts should be immutable, traceable, and verifiable. Every artifact should have a clear lineage: where it was built, which inputs were used, and which pipeline produced it. If that lineage cannot be established, the artifact should not move forward.

This perspective aligns with emerging industry models such as Supply-chain Levels for Software Artifacts (SLSA), developed under the OpenSSF. While not prescriptive, SLSA highlights an important principle for practitioners: build systems should produce artifacts whose integrity and provenance can be independently verified as they move through environments.

Delivery Pipelines and Trust Propagation

One of the most overlooked aspects of CI/CD security is how trust is propagated or lost as artifacts move from build to test to production. A verified build can still be compromised if delivery pipelines lack controls around promotion, access, or environment separation.

Hardening delivery pipelines means reducing implicit trust. When an artifact is promoted, the pipeline should be able to answer a simple question: Why do we trust this artifact at this stage? That trust should be based on verifiable signals, not assumptions.

Clear separation between build, test, and deploy stages is not just an architectural pattern; it is a security control. Each stage boundary limits blast radius, makes unauthorized changes easier to detect, and creates natural enforcement points for policy and review.

Using Security Controls Strategically

CI/CD supply chain security often fails when teams attempt to bolt on every available control without a clear strategy. Static analysis, dependency analysis, container scanning, artifact integrity checks, and dynamic testing all have value, but only when applied intentionally.

For practitioners, orchestration matters more than volume. Early pipeline stages can focus on fast feedback and obvious failures, while later stages enforce higher confidence checks before promotion. The goal is to build a pipeline that tells a coherent security story, rather than one that simply runs tools.

Equally important is feedback timing. Security findings that arrive too late or without context are likely to be ignored. When controls are integrated into normal CI/CD workflows, they support engineering decisions instead of competing with delivery goals.

From Fast Pipelines to Verifiable Delivery

At its core, CI/CD supply chain security is about changing how teams think about delivery. Fast pipelines are valuable, but verifiable pipelines are resilient. When engineers can explain why a build is trusted, not just that it passed, they operate from a stronger security posture.

For organizations supporting critical systems, this shift is no longer optional. Software supply chain attacks do not target a single application; they target the shared infrastructure that builds and delivers everything.

By treating dependencies, artifacts, and delivery pipelines as explicit trust boundaries, practitioners can harden CI/CD systems without sacrificing speed. Not by adding friction, but by making trust traceable, enforceable, and visible at every stage of the software lifecycle.

May 21, 2026
Software Weaponization Raises DevSecOps Stakes

The threat model that DevSecOps teams have been working from for the last decade was built around accidental vulnerabilities — mistakes that needed to be found and fixed before someone exploited them. That assumption is breaking. Vulnerabilities are increasingly being treated as strategic assets, stockpiled by nation-states and threat actors and held back from disclosure until they’re useful as weapons. That shift changes what “good enough” security looks like across the software delivery lifecycle.

Mike Vizard sits down with Kate Scarcella and Tracy Ragan to dig into what software weaponization actually means in practice for engineering and security teams. Their argument is that the industry has spent years investing in pre-deployment scanning and not nearly enough in knowing what’s actually running in production. The result is sprawling estates of deployed software where teams can’t answer the basic question of which versions, in which configurations, are exposed to a newly disclosed, or quietly hoarded, vulnerability.

They also get into the mechanics of closing that gap. Stronger SBOM practices are the foundation, but only if SBOMs are continuously updated, queryable and tied to the running environment, not parked in a build artifact. From there the conversation moves into automation: using AI-assisted tooling to identify exposed assets fast, prioritize remediation against real exploitability, and push fixes downstream without manual triage at every step.

The other thread is organizational. AI is now both a tool defenders rely on and a source of new risk — data poisoning, model misuse, autonomous agents acting on stale context. Scarcella and Ragan make the case that this is the moment to break down the wall between developers, security teams and data scientists, with shared visibility, shared accountability and a runtime view of the entire software estate as the connective tissue.

May 20, 2026
OpenSSF’s CRob: ‘The Runway Is Rapidly Running Out’ on EU CRA Readiness

The EU’s Cyber Resilience Act kicks into high gear this September, and companies are still clueless about how they must obey its strictures.

MINNEAPOLIS — At Open Source Summit North America, Christopher “CRob” Robinson, Chief Security Architect for the Open Source Software Foundation (OpenSSF), spoke about the European Union’s (EU) Cyber Resilience Act (CRA). CRob warned that companies are still “running straight at that wall” as the first CRA enforcement date draws ever closer.

The CRA, for those who don’t know it, sets mandatory cybersecurity rules for nearly all “products with digital elements,” which means hardware and software, sold on the EU market, with most obligations falling on manufacturers but some also on importers and distributors. That means if you sell pretty much anything in the EU, you must include a security risk assessment; design them with secure default configurations and the ability to restore to a secure state; eliminate known exploitable vulnerabilities; and provide and deploy security updates. If you don’t, the EU will sock you with fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Scary stuff, right? You’d think companies would be working their fingers to the bone getting their goods ready for the post-CRA market. You’d be wrong.

“It’s wild,” CRob said. “We did a report last year… and we’re doing the sequel. And people still are not aware of what they need to do and are not prepared, but the runway is rapidly running out.”

How bad is it? CRob said, “62% of people in Europe were unaware of what they needed to do last year. This year it’s 66%, which is statistically the same.”

It’s even worse outside Europe. In a blog post, CRob pointed out that “The geographic disparity is even more alarming. In the United States and Canada, nearly 72% of respondents are unfamiliar with the regulation. It cannot be understated: If you are a North American company selling software products into the EU market, you are legally required to comply with the CRA. However, the majority of the neighborhood is still walking unprepared toward a September 2026 reporting deadline.”

The Linux Foundation and partners had expected their second CRA readiness survey to show clear progress after a year of talks and guidance aimed directly at manufacturers and developers. Instead, the tech business remains oblivious.

“The TL;DR is we and other groups within the industry have been working on this very hard for a year, and we thought we had done a better job of getting in the rooms where the manufacturers or developers are,” CRob said. “We had expected that the second iteration of the report was going to be amazing… but the results are very middling.”

Looking ahead, the Linux Foundation is taking its message to Brussels, the de facto EU capital, in June. There, “we’re going to talk with the European Commission and ENISA.” In addition, Linux Foundation Europe will host a European policy day on June 8, followed by a June 9 event focused “purely on cyber security, mostly the CRA,” but Robinson expects the AI Act will also be on the agenda. In short, ” people need to wake up.”

Robinson argues that CRA compliance cannot be delegated to technical teams alone and says senior executives are not yet sufficiently engaged. “It’s an urgent wake‑up call, that’s for damn sure,” he added, “You need the C-suite, and it needs to get involved. This can only happen from the top down, and they’re just not going to pay attention to the open-source conferences.”

Beyond awareness, Robinson says many companies are making structurally bad bets about how to meet CRA obligations around vulnerability management and updates. In a separate Linux Foundation economics study on ROI for Open Source Software Contribution, he cites “a little over half” of organizations reporting that they “passively wait for upstream to do something before they react.”

“With the CRA, Robinson continued, “that’s like a really bad move because the upstream doesn’t have the deadlines and the fines,” he said. “They’ll try to work as quickly as they can, but… they’re not going to be yelled at or threatened to work any faster.”

Others respond by forking open source code and maintaining private branches: “They’ll do private forks, where they’ll have a private copy, they might do their own patches and not contribute that upstream,” Robinson said. “That was like over almost $260,000 of either expense or engineering labor for each product release by those organizations, that’s the technical bet they’re taking.” He argues that those numbers should “wake up the C-suite,” given the number of releases many vendors cut each year.

For large organizations (5,000+ employees), CRob added, “This burden exceeds 11,152 labor hours per cycle. Maintaining these divergent codebases is a giant bill for a strategy that actually makes supply chain transparency worse. Contributing fixes upstream isn’t just being a ‘good neighbor’ – it’s the only financially rational path forward.”

Robinson also links CRA readiness to the rapid adoption of AI in software security, which he says will massively increase the volume of fixes vendors must handle. “It’s an explosion of AI. I see it in three tiers right now.”

At the top are upstream maintainers, who he expects will “figure a way to manage this” by automating and leveraging new tools, but who will also generate “exponentially more patches every day.” The second tier consists of manufacturers “on the hook for things like the CRA,” who must “retool internal processes that have existed for decades… very conservative, very brittle, slow processes.”

The third, and in his view least prepared, group is downstream enterprises such as “a bank, or a hospital, or whatever.” “All these people… are totally unprepared for thousands of fixes hitting their inbox,” Robinson warned, adding that bad actors will inevitably weaponize AI‑driven vulnerabilities and exploits. He asked, “How do we prepare purely downstream consumers to be able to take these patches, deploy them quickly, so that they aren’t… a victim to some attack?”

That’s a good question, and for now, there are no good answers. Companies will soon have no choice but to figure it out. All the hysteria about how bad Y2K was going to be turned out to be so much hype because the hard work had already been done. When it comes to the CRA, however, far too few companies have done their homework.

May 20, 2026
1Password Allies With OpenAI to Secure Codex AI Coding Tool

1Password and OpenAI today revealed they have integrated a Model Context Protocol (MCP) server to the Codex artificial intelligence (AI) coding tool to better secure developer credentials.

As a result, Codex credentials can now be issued on a just-in-time basis to ensure secrets are not logged, cached, reused across sessions or surfaced in unexpected outputs. Instead of sharing .env files or hardcoding credential values, application developers access a shared environment where secrets are made available at runtime, without the values ever appearing in code, terminals, or model context.

1Password CTO Nancy Wang said, with that approach, in effect, developers can grant Codex access to credentials directly inside their coding workflows while keeping secrets outside of code. The MCP server does not read or return secret values through the MCP channel, surface secrets in the model’s context window, or write them to disk. Codex can create environments, list variable names, and invoke applications that use those secrets, but the values themselves never leave the 1Password vault.

As a result, DevSecOps teams can manage coding agents as a tenant rather than another vault where secrets might be stored. Secrets remain encrypted and centrally managed, with access limited to authorized users who have been granted customized permissions, said Wang. Under no circumstances is credential data ever exposed to an AI agent or large language model (LLM) as plain text, she added.

1Password is now making a case for managing the credentials granted to human developers and their AI agents via the same platform, said Wang. In time, 1Password will extend that reach to include multiple AI coding tools, she added.

The credential developers use to access application development environments have always been a rich target for cybercriminals who are trying to inject malware into a downstream application or IT environment. However, with the rise of AI agents that are capable of autonomously performing a wide range of tasks, the amount of havoc cybercriminals can potentially wreak using a stolen set of credentials is now substantially greater.

Naturally, it’s still early days so far as adoption of AI coding tools, but it’s now more a question of when rather than if they will be targeted. Cybersecurity syndicates have in recent years demonstrated a keen interest in software supply chains that, if compromised, can provide often unfettered access to IT environments that might not be discovered, if ever, for months.

Unfortunately, too many developers are still relying on traditional passwords to access tools and platforms, even though they can be easily stolen. More challenging still, many of those tools and platforms may not even be managed by cybersecurity teams that, through hard-won experience, have a greater appreciation for the need to protect credentials.

The hope is, of course, that application development and cybersecurity teams are now proactively working more collaboratively to secure software supply chains in the wake of a series of high-profile attacks. The degree to which those efforts will succeed will naturally vary from one organization to another. The one certain thing is that continuing to rely on traditional passwords to access DevOps tools and platforms is now little more than an open invitation to disaster.

May 20, 2026
Why DevOps Is Critical for Modern Business Resilience

Today’s business world operates in a state of constant change. What the customer wants to buy changes quickly, new competitors appear overnight, and cyber threats are changing faster than ever. In this world, the concept of “resilience,” the ability to adapt, to overcome, and to continue to create value for the enterprise despite the changes, has become a top-level imperative for cybersecurity and technology executives. DevOps, the cultural and technical movement to unify the software development and operations disciplines, has come of age as a key enabler of business resilience.

Bridging the Dev and Ops Divide: A Culture of Resilience

Before DevOps, many organizations were stuck in a cycle of slow releases and siloed teams. Developers would work in isolation for months before handing code off to QA and operations teams for deployment. This adversarial approach to software development hindered innovation within organizations such as Amazon, Netflix, and Google until they adopted a DevOps approach.

DevOps eliminates blame games in favor of shared responsibility. This allows teams to deploy faster, resolve defects in a timely manner, and improve product quality. For business resiliency, this is a crucial cultural shift because it allows teams to respond to issues rather than throwing them “over the wall” to resolve.

DevOps also allows teams to innovate faster through a microservices approach to software development. This means that an application is broken down into many small services, where each service is maintained by a small team. Each of these services also talks to other services through APIs. This allows teams to innovate faster and makes applications more flexible. However, this also requires teams to ensure that there is proper automation to avoid a reliability nightmare from all these services.

Accelerating Innovation Through Continuous Integration and Delivery

Continuous integration (CI) and continuous delivery/deployment (CD) are the technical drivers of the DevOps process. Continuous integration is the process that allows developers to automatically integrate their code into a shared repository, which resolves any conflicts. Continuous delivery and deployment go one step further and allow the code to be deployed into production with minimal or no human intervention. This process allows companies like Amazon to deploy hundreds of “mini-releases” every day.

Cloud native tools help to further improve this process. In a recent article featured on the online magazine devopsy.kinsta.cloud, the authors discuss how tools like Kubernetes, Docker, and Prometheus allow developers to “take advantage of the benefits of a microservice architecture and gain greater scalability and resilience in their applications.” These tools allow developers to automatically manage their containers across clusters and automatically heal failed application components.

In the words of Segun Onibalusi, CEO of Detutu Media, “Resilience isn’t just about surviving outages; it’s about designing systems that adapt and recover faster than your customers notice.” By embedding automation into every stage from code commit to deployment, teams can minimize human error and shift from reactive firefighting to proactive resilience engineering.

DevSecOps: Security as a First‑Class Citizen

With cyber threats becoming more refined, resilience and security go hand in hand. Traditionally, security has often been an afterthought in software development, something that is added at the end of the process. This has resulted in frustration for developers and put the business at risk.

DevSecOps, as a practice, changes this. DevSecOps combines culture and technology to ensure security is included at every step in the software development life cycle. If security is a shared responsibility and included in the process, as opposed to being an afterthought, security issues are caught and fixed earlier in the life cycle, when they are exponentially cheaper, faster, and easier to fix.

Security in the pipelines includes automated static and dynamic security, dependency checking, and infrastructure as code, in addition to functionality. Buy-in from the business is also required. Security must be viewed as a business enabler, not as a roadblock. Eliminating silos in DevOps, security, and development teams helps foster empathy and stops the blame game that often results in traditional software development methodologies. DevOps is an opportunity for security teams to reduce the need for security to operate as a siloed function. DevOps allows security teams to embed security expertise directly into the products.

Observability and AI: Seeing Problems Before Customers Do

However, it’s also important to remember that resilience is all about timely identification of issues and responses to those issues in a timely manner. The more complex a system is, with more layers of complexity, the more critical real-time visibility becomes. A single observability solution that integrates metrics, logs, and traces provides a holistic view of system performance. Proactive monitoring helps teams get a heads-up about issues before users are impacted. And then there’s AI/ML observability, which gets even more precise in its identification of issues and helps teams trace issues to their root causes.

For those in cybersecurity, this means faster identification of issues or security breaches. But when AI/ML is integrated into a system’s operation, MLOps helps to extend DevOps to data science to improve system resilience across the entire data stack.

Active‑Active Architectures and Disaster Recovery

Resilience isn’t created by automation or culture; it’s created by architectural choices that eliminate single points of failure. An article on active-active architectures at devopsy.kinsta.cloud states that “far too many organizations are still relying on the ‘hope and pray’ strategy of single-site applications or passive failover. Running the same application across multiple data centers or cloud regions simultaneously, with traffic routed to the closest active application instance, provides much faster response times for disaster recovery.”

Of course, the challenge with this kind of strategy is keeping the data in sync, determining what the application really needs, and treating each type of data correctly. Not all data requires real-time replication. Treating each type of data correctly can help find the right balance between resilience, cost, and complexity.

Culture and Business Continuity: Automate, Document, and Empower

It’s not just the tools or the architecture. Resilience is people. Leaders must create a culture of experimentation, learning, and collective responsibility. As the DevSecOps guide frankly states, “Culture represents about 80% of the effort. Tools alone will never overcome silos and build trust.”

Leaders must secure the resources, uplift the security champions, and create a psychological sense of safety so people feel comfortable confessing their failures. This sense of safety enables the retrospectives to lead to positive changes.

Recording how processes are executed and using automation to reduce tedious tasks also enhances the ability to maintain continuity. DevOps consultant Eficode, a Finnish DevOps consultant, noted how the COVID-19 pandemic demonstrated the value of DevOps and cloud-based software development for companies to adjust to the unexpected changes caused by the virus.

Well-documented and automated software development enables companies to rapidly respond to changes in the marketplace, identify issues, and create greater business resiliency through a series of rapid cycles. This is a key point to remember: business resiliency isn’t developed during a crisis but through deliberate preparation.

Conclusion: Building Resilience Through DevOps

But modern business resilience is not just about backups and disaster response plans. It’s an organizational ability to detect changes, respond to them promptly, and continually adapt to them. And that’s precisely what DevOps offers, both the philosophical and technological means to develop that muscle.

For instance, by combining development and operation teams, practicing continuous integration and delivery, and integrating security practices from the start, investing in observability, and designing for resilience, teams can release software faster without compromising on security and reliability. As Segun Onibalusi puts it, “Resilience is the ability to adapt. And those that are building systems that learn and adapt fast will thrive in a world that’s constantly in flux.” And for cybersecurity professionals, DevOps is not optional; it’s an essential part of their strategic arsenal.

May 15, 2026
AWS Security Agent Brings Full Repository Code Scanning to Preview

Security teams have long relied on static analysis tools to catch vulnerabilities before code ships. Those tools are useful, but they have a fundamental limitation: they match code against known patterns. They don’t understand your application.

AWS is taking a different approach with its latest addition to AWS Security Agent. The company recently released full repository code review in preview — a feature that goes well beyond traditional scanning by reasoning about your entire codebase the way a security researcher would.

What’s New

Full repository code review is a new capability in AWS Security Agent that performs deep, context-aware security analysis of an entire codebase. It’s now available in preview at no additional charge for existing AWS Security Agent customers.

Unlike traditional static analysis tools that match code against known vulnerability patterns, full repository code review reasons about an application’s architecture, trust boundaries, and data flows to surface systemic vulnerabilities that pattern-matching tools miss.

That’s a meaningful distinction. Most SAST tools will flag a SQL injection or an exposed credential if it fits a recognized pattern. What they won’t do is trace how data moves across services, how trust boundaries are defined, or how one seemingly minor flaw could chain into a larger exploit. This new feature is designed to catch exactly that.

When vulnerabilities are found, the scanner produces developer-ready findings with transparent evidence and concrete remediation — specific fixes tied to the exact file and line, so teams can identify and address security issues faster.

The Broader Context

A full repository code review is part of a broader set of capabilities that AWS has been building into its Security Agent. The agent is designed to continuously validate application security from design to deployment, covering automated application security reviews and on-demand penetration testing.

The penetration testing feature reached general availability on March 31, 2026, making it the first of the three capabilities — design review, code review, and penetration testing — to move beyond preview. Design review and full repository code review remain in preview.

AWS Security Agent is context-aware — it understands your application design, your code, and your specific security requirements. It continuously scans for security violations and runs penetration tests on demand, instantly and without scheduling.

Under the hood, the agent runs a specialized multi-agent pipeline — a coordinated swarm of purpose-built agents, each responsible for one phase of the testing workflow. For code review specifically, that means analyzing architecture, tracking data flows, and building a picture of how the application actually behaves — not just what it looks like on the surface.

What This Means for DevOps Teams

For development teams, the most practical implication is speed and specificity. Traditional security review cycles often create friction — findings come back late, lack context, or require a security specialist to interpret. Fixes tied to specific files and lines change that dynamic.

The key differentiator is that the agent ingests source code, architecture diagrams, and documentation to understand how the application was designed before it tries to identify problems. This enables it to identify how individual vulnerabilities connect into higher-severity attack chains — the kind of chained exploits traditional scanners are architecturally blind to.

For DevSecOps practitioners trying to shift security left, that’s a significant step. Security findings that arrive with context and ready-to-implement fixes are far more likely to get addressed quickly — and correctly.

“AWS Security Agent’s full repository review shows AppSec moving from pattern-matching to architectural reasoning. That has gravity. By tracing trust boundaries, data flows, and chained exploits across the codebase, AWS positions the cloud platform itself as where security reasoning happens.”

“That reshapes procurement logic for security teams and competitive ground for scanners. Buyers will weigh whether platform-native reasoning, bundled at no extra charge, displaces tools they already license. Vendors that only match patterns will struggle to justify their place in the pipeline,” said Mitch Ashley, VP and Practice Lead, Software Lifecycle Engineering, The Futurum Group.

Available Now in Preview

AWS is prioritizing free early access for customers, giving defenders the opportunity to strengthen their codebases and share what they learn so the whole industry can benefit. AWS is also actively soliciting feedback via the built-in mechanism in the Security Agent web application or by contacting account teams.

For organizations already using AWS Security Agent, enabling full repository code review is accessible directly through the Security Agent console.

It’s still early, and preview status means the experience will continue to evolve. But the direction is clear: AI-assisted security that understands your application architecture, not just your code patterns, is becoming a practical option for development teams — not just a research concept.

May 14, 2026
Hacktron Plans to Build AI Platform to Test Code for Vulnerabilities

Hacktron revealed today it is developing a platform that leverages artificial intelligence (AI) to continuously test code for vulnerabilities.

Fresh off raising $2.9 million in seed capital, Hacktron founder Zayne Zhang said the company’s platform will employ multiple AI models to test every pull request and code change to identify vulnerabilities that are actually exploitable.

Once identified, the platform will also surface a recommendation to remediate that issue that could be shared with an AI coding tool. The overall goal is to dramatically reduce the number of false positives that DevOps teams waste time investigating, said Zhang. In effect, AI will significantly reduce the current level of burden DevSecOps teams today experience when trying to maintain application security, he added.

The team behind Hacktron has years of expertise researching vulnerabilities. Most recently, Hacktron uncovered critical vulnerabilities in the widely used OAuth2 Proxy project, highlighting risks in open-source infrastructure relied on by enterprise teams. The company has also provided security testing services for organizations such as Perplexity AI and Supabase.

With the advent of the latest AI models from Anthropic and OpenAI, it’s apparent that vulnerabilities in code will soon be discovered within hours of an application being deployed. Once discovered, it will only take a few more hours for adversaries to find ways to exploit those vulnerabilities. The only way to prevent those cybersecurity incidents in the first place will be to leverage AI to identify and remediate vulnerabilities and weaknesses long before any application is actually deployed, noted Zhang.

It’s not clear how much time DevOps teams will soon be spending on remediating vulnerabilities as more of them are discovered, but there is a case to be made for replacing or modernizing legacy applications on the assumption many of them are, from a security perspective, fundamentally flawed. The challenge then becomes making sure that any new code generated by human developers or an AI agent is truly secure. Otherwise, DevOps teams will find themselves throwing more fuel on an application security fire that is already close to spiraling out of control.

Regardless of approach, there will soon come a day when it will no longer be acceptable to ship code that has known vulnerabilities. The irony, of course, is that the first wave of AI tools that application developers adopted tended to increase the number of vulnerabilities being introduced simply because they were trained using flawed examples of code. However, the next generation of AI models have more advanced reasoning capabilities that makes it possible to surface vulnerabilities in both new and legacy code.

Ultimately, it’s now only a matter of time before DevSecOps workflows are re-engineered using AI agents that will be better at discovering vulnerabilities than most software engineers might ever hope to be. While that may lead to some fundamental changes in how DevOps workflows are constructed, there is little doubt that most of the application developers that spend time creating and testing patches for applications would, as a rule, generally prefer to be spending more of their time on higher level tasks that add significantly more value to the business.

May 13, 2026
Continuous Security in DevSecOps: Moving Beyond One-Time Testing
Waiting for a single annual pentest to secure your application is like locking your front door only once a year and hoping for the best. In an era where 133 new vulnerabilities are reported every single day, relying on periodic snapshots leaves your organization exposed to evolving threats for months at a time.

This approach is no longer just risky; it is a significant financial liability. Data from the IBM Systems Science Institute highlights that fixing a bug in production costs 100 times more than catching it during the initial design phase. For modern teams, the ‘window of vulnerability’ between tests is where attackers find their greatest opportunities.

Transitioning to continuous security in DevSecOps is the only way to close this gap. By embedding automated validation into your CI/CD pipeline, you move from a reactive ‘checkbox’ mentality to a proactive, resilient posture. This guide explores how to move beyond one-time testing to build a defense that evolves as fast as your code.

What is Continuous Security in DevSecOps?

Continuous security in DevSecOps means integrating security checks into every stage of the software development life cycle. It is not a one-time audit. It runs alongside your code, from the first commit to production deployment.

Traditionally, security testing happened at the end. That model does not work anymore. With faster release cycles, vulnerabilities left unchecked for weeks can cost companies an average of $4.44 million per breach, according to IBM’s 2025 report.

In DevSecOps, security becomes part of the pipeline itself. Automated scanning, real-time threat detection and policy enforcement run continuously. Every build gets checked. Nothing waits for a quarterly review.

The Problem With One-Time Security Testing

Most teams still treat security like a final checkbox. You build the product, hand it over to the security team and wait for a report. That process made sense 10 years ago. It does not make sense now.

Release cycles have shortened dramatically. Teams ship code daily, sometimes multiple times a day. A penetration test done once a quarter cannot keep up with that pace. New vulnerabilities get introduced with every pull request.

The numbers back this up. According to Veracode, 76% of applications have security flaws on initial scan. Most of those flaws come from code written between testing cycles. That gap is where attackers operate.

One-time testing also creates a false sense of security. You pass the audit, check the box and assume you are covered. But your attack surface keeps changing. Static snapshots of security do not protect dynamic, constantly evolving systems.

Core Principles of a Continuous Security Model

Building continuous security is not about adding more tools. It is about changing how security fits into your entire development process. These five principles form the foundation of that shift.

1. Automate Security at Every Stage

Manual reviews cannot scale with modern development. Automated security checks need to run at every stage of your CI/CD pipeline. From code commit to deployment, automation catches issues before they reach production. It removes the human bottleneck without removing human judgment.

2. Shift Security Left Without Abandoning the Right

Shifting left means catching vulnerabilities early in development. But security cannot stop there. Runtime monitoring, post-deployment scanning and incident response all matter just as much. A strong continuous security model covers the full software delivery life cycle (SDLC), not just the beginning of it.

3. Treat Security as a Shared Responsibility

Security is not just the security team’s job. Developers, DevOps engineers and product teams all play a role. When everyone understands their part, vulnerabilities get caught faster. Building a security-aware culture is just as important as any tool you deploy.

4. Integrate Threat Intelligence in Real-Time

Static threat models go stale fast. Continuous security means feeding real-time threat intelligence into your pipeline. When new vulnerabilities are disclosed, your system should respond immediately. Waiting for the next scheduled review gives attackers a window they will use.

5. Measure, Monitor and Improve Continuously

You cannot improve what you do not measure. Track metrics such as mean time to detect, vulnerability closure rate and false-positive rates. Regular review of these numbers tells you where your security program is strong and where it needs work. Continuous improvement is the goal.

How to Integrate Continuous Security in DevSecOps

Integrating continuous security into DevSecOps is not a one-day project. It is a step-by-step process that embeds security controls directly into your development and deployment workflows.

Step 1: Audit Your Current Pipeline

Before adding anything new, understand what you already have. Map out every stage of your CI/CD pipeline and identify where security checks are missing or manual. This gives you a clear picture of your gaps before you start filling them.

Step 2: Embed SAST DAST Early

Static application security testing (SAST) should run on every code commit. Dynamic application security testing (DAST) should follow in your staging environment. Running both consistently means vulnerabilities get caught at the source, not weeks later during a scheduled review.

Step 3: Automate Dependency Scanning

Third-party libraries are one of the biggest sources of risk. Use software composition analysis (SCA) tools to automatically scan dependencies with every build. Tools like Snyk or Dependabot flag known vulnerabilities in open-source components before they make it into production.

Step 4: Secure Your CI/CD Configuration

Your pipeline itself is an attack surface. Harden your CI/CD configuration by enforcing least-privilege access, securing environment variables and auditing pipeline scripts regularly. A compromised pipeline can undo every other security control you have put in place.

Step 5: Add Runtime Security Monitoring

Security does not stop at deployment. Implement runtime protection tools that monitor application behavior in production. Solutions such as Aqua Security and ZeroThreat.ai can detect anomalous activity and trigger alerts the moment something unusual happens in your live environment.

Step 6: Set Security Gates in the Pipeline

Define clear pass/fail criteria for security checks. If a build introduces a critical vulnerability, it should not move forward. Security gates enforce standards automatically and remove the pressure of manual judgment calls during fast-moving release cycles.

Step 7: Improve Continuously

Continuous security never truly ends. Schedule regular reviews of your security metrics, tooling and policies. As your application evolves, your security posture needs to evolve with it. Treat it like any other part of your engineering process, always improving.

Top DevOps Tools for Continuous Security

Selecting the right tools is the foundation of a successful continuous security strategy. You need solutions that not only find vulnerabilities but also integrate smoothly into your existing development workflows without causing delays.

Here are the best picks for ensuring security right from your CI/CD pipelines:

1. Burp Suite

Burp Suite is a widely used web application security testing platform known for its strong manual penetration testing capabilities. It works as an intercepting proxy, allowing testers to analyze and modify HTTP and HTTPS traffic to uncover vulnerabilities in real-time.

It supports the full testing workflow, from mapping the attack surface to identifying complex vulnerabilities. While it includes automated scanning, it is mainly preferred for deep, expert-driven testing where precision, context and detailed validation are required.

Key Features of Burp Suite:
- Intercepting proxy for HTTP and HTTPS traffic analysis
- Advanced vulnerability scanning and crawling
- Intruder tool for fuzzing and attack simulation
- Repeater for manual request testing and validation
- Session handling and authentication testing
2. OWASP ZAP

OWASP ZAP is an open-source web application security scanner designed for both beginner and experienced teams. It provides automated vulnerability scanning along with proxy-based testing, making it a flexible tool for integrating security into development workflows.

It is widely used in DevSecOps environments because of its automation capabilities and CI/CD compatibility. ZAP performs both passive and active scanning, helping teams detect common vulnerabilities continuously without requiring heavy manual effort.

Key Features of OWASP ZAP:
- Automated passive and active vulnerability scanning
- REST API support for CI/CD integration
- Intercepting proxy for traffic inspection
- Scriptable interface for custom testing
- Strong community support and extensions
3. ZeroThreat.ai

ZeroThreat.ai is a modern, AI-powered automated penetration testing platform. It supports the DevSecOps approach with simplified CI/CD integration. The tool simulates real attacker behavior to identify exploitable vulnerabilities across web applications and APIs, going beyond traditional vulnerability scanning.

It focuses on continuous validation by chaining vulnerabilities, testing business logic and running security checks across staging and production. This helps teams identify real risk exposure and maintain strong security posture without slowing down release cycles.

Key Features of ZeroThreat.ai:
- Agentic attack path simulation for real-world testing
- Exploit chaining and business logic vulnerability detection
- Continuous, production-safe automated pentesting
- CI/CD integration for ongoing security validation
- AI-driven risk prioritization and remediation insights
4. Mend

Mend is a software composition analysis platform designed to secure open-source dependencies across the development life cycle. It helps teams detect vulnerabilities, license risks and malicious packages early, directly within developer workflows and CI/CD pipelines.

It stands out with reachability analysis, which focuses on exploitable vulnerabilities instead of noise. Mend also provides real-time alerts and automated remediation, allowing teams to fix issues faster while maintaining visibility into software supply chain risks.

Key Features of Mend:
- Advanced reachability analysis for real risk detection
- Automated vulnerability remediation workflows
- Open-source dependency and license compliance scanning
- SBOM generation and supply chain visibility
- CI/CD and IDE integrations for continuous security
5. Semgrep

Semgrep is a lightweight static analysis tool that helps developers find security vulnerabilities directly in source code. It supports multiple languages and integrates easily into CI/CD pipelines, making it a strong choice for continuous code security testing.

It uses rule-based semantic analysis, allowing teams to customize detection logic based on their codebase. With support for SAST, SCA and secrets detection, Semgrep enables fast and flexible security checks without slowing development workflows.

Key Features of Semgrep:
- Static application security testing with semantic analysis
- Custom rule creation for tailored vulnerability detection
- CI/CD and IDE integration for continuous scanning
- Multi-language support across modern stacks
- Combined SAST, SCA and secrets detection capabilities
6. Black Duck

Black Duck is an enterprise-grade application security platform focused on managing open-source and third-party risks. It provides deep visibility into dependencies, helping teams identify vulnerabilities, compliance issues and supply chain threats across the entire SDLC.

It combines multiple scanning techniques, including dependency, binary and snippet analysis, to detect hidden risks. With continuous monitoring and automated policy enforcement, Black Duck ensures secure software delivery at scale.

Key Features of Black Duck:
- Comprehensive SCA for open-source risk management
- Multi-layer scanning including binary and snippet analysis
- Continuous monitoring of dependencies and vulnerabilities
- SBOM generation and compliance tracking
- Integration across CI/CD pipelines and developer tools
7. Spectral

Spectral is a developer-first security platform focused on detecting secrets, misconfigurations and sensitive data exposure in codebases. It continuously scans code, logs and assets to prevent credential leaks and reduce security risks early.

It uses AI-powered detectors and integrates directly into CI/CD pipelines and pre-commit workflows. This allows teams to identify exposed API keys, tokens and sensitive data before they reach production environments.

Key Features of Spectral:
- Secrets scanning with thousands of built-in detectors
- Real-time detection of API keys, tokens and credentials
- CI/CD and pre-commit integration for early detection
- AI-powered risk detection across code and assets
- Custom rule creation for organization-specific policies
Wrapping Up

Security can no longer be treated as a final checkpoint. Modern DevOps teams deploy multiple times a day, and each release can introduce new risks. To tackle this, continuous security must be embedded for automating security testing, monitoring and validation into every stage of the life cycle. It ensures vulnerabilities are identified early, fixed faster and never left unnoticed as new deployments are made. This shift helps build a resilient security posture that keeps pace with fast-paced SDLC.
May 12, 2026
Beyond the Build: Integrating Security into CI/CD Pipelines
In today’s fast-paced software development landscape, Continuous Integration and Continuous Deployment (CI/CD) pipelines are essential for delivering applications efficiently. However, the speed and automation they offer can inadvertently introduce security vulnerabilities if not properly managed. Integrating security into CI/CD pipelines, often referred to as DevSecOps, is no longer optional; it’s a necessity.

The Importance of Security in CI/CD

Traditional security practices often occur late in the development cycle, leading to delays and increased costs when vulnerabilities are discovered. By embedding security checks into the CI/CD pipeline, teams can identify and address issues early, reducing risk and maintaining development velocity.

Key Strategies for Integrating Security
Automated Security Testing
Incorporate tools that automatically scan code for vulnerabilities during the build process. Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools can identify common issues without manual intervention.

Dependency Management
Use Software Composition Analysis (SCA) tools to monitor third-party libraries and dependencies for known vulnerabilities. Keeping dependencies up-to-date is crucial for maintaining a secure codebase.

Infrastructure as Code (IaC) Scanning
As infrastructure is increasingly managed through code, it’s vital to scan IaC templates for misconfigurations that could lead to security breaches. Tools like Terraform and CloudFormation scanners can automate this process.

Secret Management
Ensure that sensitive information, such as API keys and passwords, are not hardcoded into the codebase. Implement secret management solutions to handle credentials securely.

Continuous Monitoring and Feedback
Establish monitoring systems that provide real-time feedback on security issues. This continuous feedback loop enables teams to respond quickly to new threats and maintain a strong security posture.
Conclusion

Integrating security into CI/CD pipelines is essential for modern software development. By adopting automated tools and practices, teams can proactively address vulnerabilities, ensuring that security keeps pace with rapid development cycles. Embracing DevSecOps not only protects your applications but also builds trust with users and stakeholders.
May 7, 2026
The Messy Reality of Vibe Coding

The default reaction to vibe coding has been alarm — a default assumption that letting AI write large chunks of an application is going to flood production with vulnerabilities and undocumented behavior. That fear is doing as much damage as the bad code people are afraid of. Teams that freeze, ban the tools or push the work into the shadows end up with less visibility into how AI is actually showing up in their codebase, not more.

Tyler Merritt, CTO at UneeQ, joins Mike Vizard to push back on the panic and reframe the problem. Merritt’s argument is that AI-assisted development is a construction site, not a finished building — and construction sites are inherently messy. The job for engineering leaders isn’t to keep the site spotless, it’s to make sure the right safety systems, inspections and review steps are wrapped around the work that’s happening anyway.

They get into the practical mechanics of doing that. Instead of trusting any single model, Merritt makes the case for using multiple AI assistants — Claude, Gemini and others — as a kind of cross-check, where one model reviews what another produced and pulls weaknesses to the surface before they hit a pull request. Pair that with the existing toolchain (SAST, dependency scanning, code review, tests) and the AI output starts to look more like any other developer’s output: imperfect, but reviewable.

The longer-term view is more optimistic than the headlines suggest. Merritt points out that no developer wakes up wanting to ship insecure code, and as these assistants get better at understanding context, security and intent, they have a real shot at making the secure path the easy path — turning today’s messy reality into a faster, safer way of building software.

May 7, 2026