devopsy.kinsta.cloud

Tag: devsecops automation

Agentic DevSecOps: AI Security Co-Pilots for Your CI/CD Pipeline
The emergence of AI has brought endless possibilities and innovative opportunities in today’s ever-changing, fast-paced technology landscape. AI is helping development teams produce software significantly faster than ever before.

AI-enabled DevSecOps tools can automatically scan code, infrastructure and other configurations for security issues throughout development, accelerating the overall process.

The introduction of agentic AI into the software development life cycle (SDLC) ensures less time and effort are spent on risk assessments and that incidents can be remediated far more quickly than with traditional methods.

The Need for an Agentic Layer in DevSecOps

Presently, many organizations use AI as part of the DevSecOps process to automate security tasks and improve efficiency in delivering and integrating code before deployment. Most organizations have access to multiple security tools; however, these tools do not work together to provide a comprehensive solution for the organization’s overall security posture, creating potential gaps and vulnerabilities.

Agentic AI automates security testing across the entire DevSecOps pipeline and enhances your ability to detect and remediate vulnerabilities throughout the SDLC. Agentic AI also allows you to have an ongoing understanding of your security posture throughout the entire software development process. It provides autonomous agents that can help you secure, optimize and manage your DevSecOps pipelines.

The DevSecOps process has always included security throughout the development life cycle, so by integrating an agentic layer into the software, the person or team developing can continuously access security guidance and assessments throughout the process, rather than waiting until the end of the development cycle.

While it is advantageous for an agentic security co-pilot to monitor events occurring in an automated delivery pipeline, an agentic security co-pilot must also have access to and the ability to analyze data from multiple input sources (event logs, code repositories, etc.) to make recommendations or trigger precursory actions in accordance with corporate policy and business rules.

Thus, agentic security co-pilots should possess both limited decision-making authority and the capacity to operate autonomously under a predefined set of corporate policies and business rules.

Agentic AI vs. Traditional Automation Approaches

Agentic AI comprises a collection of autonomous, decision-making AI agents capable of proactively managing and optimizing development, security and operations tasks.

Additionally, these AI agents continuously learn, adapt and take action within your continuous integration/continuous delivery (CI/CD) pipeline to secure your code, improve its quality and accelerate software delivery.

Agentic AI uses autonomous AI agents to optimize, manage and secure DevOps and security pipelines.

Unlike traditional DevOps, wherein security is embedded into the SDLC, agentic AI provides an additional layer of intelligence, helping facilitate decision-making and coordinate activities across teams and tools, rather than relying on manual security-embedding.

Agentic AI also allows DevSecOps to evolve from a rule-based automated process to an intelligent, orchestrated process. An added benefit of agentic AI is its ability to continuously monitor and analyze log files, network traffic and runtime activity. Agentic AI provides proactive security testing when developing software, as opposed to traditional methods of automating security testing that react to security vulnerability exploits after they happen.

Traditional automation runs security tests on the software after it has been developed and is ready to be shipped. Agentic AI enables the creation of security tests for software based on context and provides real-time incident response.

Steps for Integrating Agentic AI Into DevSecOps

Agentic AI searches your source code, configuration data and infrastructure to detect potential security risks and vulnerabilities in real-time, providing meaningful, valuable insights. Successful integration of agentic AI into DevSecOps depends on establishing a process that includes the following steps:

Step 1: Analyze Existing Security Practices

You should first analyze your existing development and security processes and see where you can improve. Using results from the analysis of current security practices can help you develop AI-enabled solutions that will meet your specific development needs.

Step 2: Integrate AI Tools Into DevOps Pipelines

Next, you should add agentic AI to your DevSecOps pipeline to enable automated security testing, vulnerability scanning and threat monitoring. With AI incorporated into your DevSecOps pipeline, you can quickly identify and mitigate security vulnerabilities and threats in real-time without affecting your development projects.

Step 3: Automate Threat Detection

In the next step, use agentic AI to continuously scan and assess your software, configurations and infrastructure for potential vulnerabilities. Additionally, you can set up notifications to alert your DevOps teams so they can take action proactively and mitigate identified risks before they become more severe.

Step 4: Continuously Monitor

Now that you’ve automated threat detection, the next step is to incorporate agentic AI’s real-time threat intelligence capabilities to remain aware of the security threats continually affecting your IT environment. The agentic AI system can provide automatic remediation recommendations to eliminate existing threats or notify your security responder team of the incident.

Step 5: Educate and Train

Finally, you should train and educate your development and security teams to understand how to effectively integrate AI into their respective workflows. With this knowledge, teams can better leverage agentic AI capabilities to achieve optimal results when securing their development environments.

Agentic AI Integration Into DevSecOps: An Architectural Overview

Typically, six stages flow vertically through your entire software development pipeline.
- Plan and Code: The team creates and documents what to code.
- Build and Test: The code is compiled and then run through tests to ensure there are no defects.
- Package: The compiled code or built artifact is prepared for release.
- Deploy: The package is deployed to a specific environment.
- Monitor: The application is monitored for potential runtime issues.
- Loop: In this stage (indicated by dashed arrows), feedback from monitoring is sent to the plan and code stage, forming a complete loop.
Figure 1 illustrates a typical DevSecOps pipeline integrated with agentic AI and how agentic AI intercepts the workflow at various stages.

Figure 1: A Typical DevSecOps Pipeline Integrated With Agentic AI Security

There are three main checkpoints where the agentic AI intercepts your DevSecOps pipeline:
- During the build and test stage, before finalizing the build, the agentic AI can inspect for potential security vulnerabilities, code quality and policy violations.
- During the package stage, before storing or releasing an artifact, the agentic AI can alert teams about any issues with the artifact that will be produced.
- During deployment, the agentic AI approves or disapproves an application’s production-readiness.
Takeaways
- As applications become more complex and diverse, there will be a greater need for continuous monitoring and improvement in the SDLC.
- Agentic AI can help improve DevSecOps by enabling real-time threat detection, autonomous security testing and intelligent pipeline management using an AI-first approach.
- Agentic AI is made for DevSecOps and uses autonomous AI agents to optimize, manage and secure the DevOps and security pipelines.
- Agentic AI also provides proactive security testing, as opposed to traditional methods of automating security testing that react to security vulnerability exploits after they happen.
- Most organizations have too many security tools at their disposal, but they are often not connected to each other, creating security gaps and vulnerabilities.
- Today, organizations are using AI to automate DevSecOps processes, enabling quicker, less resource-intensive integration, testing, deployment and monitoring of software.
- Although you can leverage AI to continue developing software at an incredibly quick pace, you now need to be more aware of the security implications and ensure they don’t negatively impact software delivery.
June 5, 2026
Anthropic Brings AI-Powered Security Scanning to Enterprise Teams With Claude Security

Anthropic has launched Claude Security in public beta for Claude Enterprise customers. The tool gives security teams a way to scan entire codebases for vulnerabilities — and generate targeted patches — without the usual back-and-forth that slows down remediation.

It’s a meaningful step forward for teams struggling to keep pace with the growing volume and complexity of security threats. And it signals where AI-assisted development is heading next.

From Research Preview to Public Beta

Claude Security isn’t brand new. Anthropic first released it as Claude Code Security in February, initially limited to Enterprise and Team customers. Since then, hundreds of organizations have used it in production, surfacing vulnerabilities that existing tools had missed — in some cases, for years.

That real-world feedback shaped what’s shipping today.

The public beta is now open to all Claude Enterprise customers globally. Access for Team and Max plan users is coming soon.

How it Works

Claude Security is powered by Claude Opus 4.7, Anthropic’s latest flagship model. What sets it apart from traditional static analysis tools is its approach to a codebase.

Rather than scanning for known patterns or signatures, it traces data flows, reads source code, and examines how components interact across files and modules — as a security researcher would. That reasoning-based approach means it can surface vulnerabilities that rule-based tools are likely to miss entirely.

Each finding undergoes a multi-stage validation pipeline before reaching an analyst. Every result comes with a confidence rating, severity level, likely impact, reproduction steps, and a recommended fix. Teams aren’t just getting a list of issues — they’re getting actionable intelligence.

From there, users can open a Claude Code session and work through the patch in context. No lengthy ticket queue. No waiting on a separate engineering review cycle. The goal is to go from scan to fix in a single sitting.

Since the research preview, Anthropic has also added scheduled scans for continuous coverage, the ability to dismiss findings with documented reasoning (so future reviewers can trust prior triage decisions), and CSV and Markdown export for integrating results into existing tracking and audit workflows.

Built for How Security Teams Actually Work

One of the more practical aspects of Claude Security is that it doesn’t require teams to abandon their current tooling. Findings can be exported in formats that plug directly into existing tracking systems. Dismissed findings carry documented context. Scheduled scans run in the background without requiring manual triggers.

That last point matters. Security teams are already stretched. A tool that runs independently and surfaces meaningful results — rather than generating noise — is far more likely to get adopted and used consistently.

According to Mitch Ashley, VP and practice lead for software lifecycle engineering at The Futurum Group, “Anthropic moving Claude Security to public beta collapses application security detection and remediation into one agent-driven workflow. Opus 4.7 reasoning across data flows, and component interactions compresses the scan-find-fix cycle into a single sitting, eliminating the ticket queue handoffs that defined traditional AppSec.”

“Pressure lands on vendors selling findings as the product. With endpoint and cloud security platforms embedding Opus 4.7 directly, the model layer is becoming a substrate for the security stack. Incumbents whose value lives in the detection-fix gap have to close it or lose the workflow.”

Part of a Broader Security Push

Claude Security doesn’t exist in isolation. It’s part of a wider effort by Anthropic to put advanced AI capabilities in the hands of defenders.

Opus 4.7 ships with safeguards that automatically detect and block requests indicating prohibited or high-risk cybersecurity uses. Those guardrails are built into the model itself, not bolted on as a filter. Anthropic has also launched a Cyber Verification Program for security professionals who need to use Opus 4.7 for legitimate purposes like vulnerability research, penetration testing, and red-teaming.

Alongside Claude Security, Anthropic launched Project Glasswing — an initiative focused on securing systemically important software and infrastructure. That program uses the company’s more restricted Mythos model, which is not publicly available and accessible only through a controlled consortium of technology partners.

Strong Partner Ecosystem From Day One

The public beta launch also comes with a notable list of integration partners. On the technology side, CrowdStrike, Palo Alto Networks, SentinelOne, Trend.ai, and Wiz are incorporating Opus 4.7 into their cybersecurity platforms. Service partners, including Accenture, BCG, Deloitte, Infosys, and PWC, are deploying Claude to help enterprise customers strengthen their overall security posture.

That partner network gives organizations options. Whether they want a standalone tool or something embedded in an existing platform they already rely on, there’s a path to adoption.

What This Means for DevSecOps

The core promise of DevSecOps has always been shifting security left — catching issues earlier in the development cycle, when they’re cheaper and faster to fix. In practice, that’s been harder than it sounds. Security reviews slow down pipelines. Findings pile up. Engineering and security teams operate in silos.

Claude Security doesn’t solve all of that. But it does address a real friction point: the gap between finding a vulnerability and knowing what to do about it. When a tool can identify a problem, explain it clearly, rate its severity, and help generate a fix — all in the same workflow — it changes the calculus for security teams.

Claude Security focuses on scanning an entire codebase with multiple agents running in parallel. While some tools look for known issues, Claude Security steps through source code and examines data flows to build a more complete picture of the attack surface.

That’s a meaningful capability — especially for organizations managing large, complex codebases where threats often hide in component interactions rather than isolated functions.

Claude Security is available now in public beta for Claude Enterprise customers. Access for Team and Max users is expected to follow.

May 1, 2026
Security as Code is Becoming the New Baseline: Continuous Compliance in DevOps

There was a time when compliance meant a quarterly ritual. Someone from security would walk over with a spreadsheet, ask a few questions, tick a few boxes and disappear until the next audit cycle. The infrastructure team would scramble to prove that yes, encryption was enabled, and no, that S3 bucket was not public anymore. Everyone felt relieved, went back to shipping features and quietly hoped nothing would drift before the next review.

That model is dead; it just hasn’t been buried yet.

The problem is not that teams lack security awareness. Most engineering organizations today understand that vulnerabilities need catching early and that production environments need hardening. The problem is that compliance has historically lived outside the delivery pipeline — treated as a checkpoint rather than a continuous practice. In a world where teams deploy dozens of times a day across multi-cloud environments, a checkpoint approach is like locking the front door while the back wall is missing.

This is where security as code changes the conversation entirely.

What Security as Code Actually Means

Security as code is not just another rebrand of DevSecOps, though the two share DNA. At its core, it means treating security policies, compliance baselines and governance rules exactly the way we treat application code. They are version-controlled, peer-reviewed, tested in CI and enforced automatically at every stage of the pipeline.

Think about how infrastructure as code (IaC) transformed provisioning. Before Terraform and CloudFormation, engineers clicked through console UIs and hoped their configurations matched across environments. IaC made infrastructure reproducible, auditable and consistent. Security as code does the same thing for compliance. Instead of documenting your security posture in a wiki that nobody updates, you encode it into policy files that are evaluated every time code moves through the pipeline.

The distinction matters. When a security policy lives in a PDF, it is aspirational. When it lives in a Git repository with automated enforcement, it is operational.

Why 2026 is the Inflection Point

Several forces are converging to make security as code not just desirable but unavoidable.

First, regulatory pressure has intensified across every sector. The EU Cyber Resilience Act, DORA for financial services, updated NIST frameworks and tightening SOC 2 requirements — all demand that organizations demonstrate continuous compliance rather than point-in-time adherence. Auditors are increasingly asking not just whether controls exist but whether they are continuously monitored and enforced. A quarterly scan no longer satisfies that question.

Second, cloud-native architectures have made manual compliance impractical. When your infrastructure is ephemeral, when containers spin up and down in seconds, when Kubernetes clusters are running hundreds of pods across multiple namespaces, no human team can manually verify that every resource meets your security baseline. The attack surface changes too quickly and too often for static checklists to keep up.

Third, and perhaps most practically, engineering teams are tired of the friction. In too many organizations, security review is still the bottleneck that sits between ‘code complete’ and ‘deployed’. Developers write a feature, submit it for security review, wait three days, get feedback, fix the issues, resubmit and wait again. This does not scale, and it breeds resentment between teams that should be collaborating. Security as code eliminates this bottleneck by making the feedback loop instant and automatic.

What This Looks Like in Practice

The tooling ecosystem has matured significantly. Open Policy Agent (OPA), now a graduated CNCF project, has become the de facto engine for policy enforcement across Kubernetes, CI/CD pipelines and API gateways. Checkov scans IaC templates against hundreds of built-in policies covering CIS benchmarks, PCI-DSS, HIPAA and NIST before a single resource gets provisioned. HashiCorp Sentinel provides policy as code for Terraform workflows. AWS Config Rules, Azure Policy and GCP Organization Policies offer native guardrails within each cloud provider.

However, tooling alone is not the transformation. What matters is the workflow.

In a mature security as code implementation, a developer writes a Terraform module to provision a new database. Before that module even reaches the plan stage, Checkov evaluates it against the organization’s security policies. Is encryption at rest enabled? Is the database accessible only from private subnets? Are backup retention policies configured? If any policy fails, the pipeline stops. The developer gets immediate feedback, fixes the issue in the same commit cycle and moves forward. No tickets. No waiting. No handoffs.

At the Kubernetes layer, OPA Gatekeeper evaluates every admission request against policies defined in Rego. Want to ensure no container runs as root? That every pod has resource limits? That images only come from your approved registry? These are not suggestions in a runbook — they are constraints enforced at admission time. Non-compliant workloads simply cannot be deployed.

The compliance evidence generates itself. Every policy evaluation produces a decision log. Every failed check is recorded. Every exception is tracked with justification and approval. When audit time comes, you do not scramble to prove compliance. You export the logs.

The Cultural Shift That Makes it Work

The technical implementation is the easier part; the harder challenge is cultural.

Security as code requires security teams to think like engineers. Instead of writing policy documents that describe what should happen, they write policy code that enforces what must happen. This is a meaningful shift in skill set and mindset. Security engineers who can write Rego, who understand Terraform module patterns, who can review pull requests on policy changes — these are the practitioners who will define how compliance works in the next decade.

It also requires engineering leadership to treat security policies as first-class code. That means they go through the same review process as application code. They have tests. They have staging environments where policy changes are validated before they reach production. When a new compliance requirement emerges, the response is not a meeting and a memo. It is a pull request.

Perhaps most importantly, it requires organizations to accept that security is not a gate at the end of the pipeline. It is a property of the system, continuously verified, just like uptime and performance.

Where Teams Get it Wrong

The most common failure mode is what I call ‘tool-first, policy-later’. Teams adopt OPA or Checkov, write a handful of policies to satisfy an immediate audit requirement and then stop. The policies become stale. New services get deployed without coverage. The tooling exists but the practice atrophies.

The second failure mode is over-restriction. Teams write policies so aggressive that developers cannot get anything deployed without filing exceptions. This recreates the exact bottleneck that security as code was supposed to eliminate, just with a different approval mechanism. Good policy design requires pragmatism. Start with critical controls — encryption, network isolation, access management — and expand gradually. Not everything needs to be a hard block on day one. Some policies can start as warnings that become enforced over time as teams adjust.

The third failure is treating security as code as solely a platform team concern. If developers never see the policies, never understand why a deployment was blocked and never contribute to policy evolution, you have just moved the silo from a spreadsheet to a repository. Policies must be visible, documented and open for contribution.

What Comes Next

The direction of travel is clear. Policy-as-code adoption is accelerating. Gartner projects that by the end of 2026, a majority of software organizations will rely on internal developer platforms with embedded policy enforcement. The CNCF ecosystem continues to invest heavily in OPA and related projects. Cloud providers are expanding their native policy engines with deeper integration into deployment workflows.

However, the real shift is not about any single tool or framework; it is about the expectation. Continuous compliance is becoming a baseline expectation, not a differentiator. Organizations that still rely on periodic audits and manual reviews will find themselves unable to move at the speed their business demands, unable to satisfy increasingly stringent regulatory requirements and unable to attract engineers who expect modern security practices.

Security as code is not the future of compliance in DevOps. For the teams paying attention, it is already the present. The rest are just catching up.

March 26, 2026
Checkmarx Acquisition of Tromzo Accelerates Plan to Apply AI to Application Security

Checkmarx has revamped its strategy for infusing artificial intelligence (AI) agents into DevSecOps workflows following its acquisition of Tromzo, a provider of an application security posture management platform (ASPM).

Earlier this year, Checkmarx committed to building three classes of AI agents within a Checkmarx Assist portfolio, starting with a Developer Assist tool that it developed. The other two Policy Assist Agent and Insight Assist Agent will now be based on AI agents developed by Tromzo to apply AI.

Ori Bendet, vice president of product management for Checkmarx, said in effect the acquisition of Tromzo accelerates the timeline the company had set for building a suite of AI agents that automate application security workflows across the entire software development lifecycle (SDLC). Checkmarx also gains a cybersecurity team that has already developed a lot of expertise when it comes to applying AI to application security, he added.

Tromzo CEO Harshil Parikh said that as a provider of an ASPM, Tromzo is already using AI to understand the unique attributes of a codebase. Whenever an issue is discovered, its AI agents will then surface code recommendations for fixing it. That approach eliminates the need for a developer to spend time researching the vulnerability and then building a patch, said Parikh.

That capability will soon be extended using data collected by the static application security testing (SAST), dynamic application security testing (DAST) and software composition analysis (SCA) tools developed by Checkmarx, noted Parikh.

The acquisition of Tromzo comes at a time when DevSecOps teams continue to struggle. A recent Checkmarx survey finds nearly all (98%) organizations have experienced a security breach attributable to vulnerable code, with 81% acknowledging their organization has shipped code with known vulnerabilities into production environments. More than a quarter of organizations (27%) experienced four or more breaches due to these vulnerabilities.

Roughly a third of respondents are resigned to additional incidents occurring in the next 18 months, with software supply chain compromise (35%) topping the list followed by a third-party vendor/partner security incident (35%), cloud infrastructure misconfiguration (34%), insider threat or privileged access misuse (33%) and application programming interface (API) security breach or business logic attack (32%).

As the pace at which applications are being developed in the age of AI continues to accelerate, many of these issues will only be further exacerbated. The only way DevSecOps teams will be able to keep pace is to rely more on AI to discover and remediate issues, many of which will be created by developers relying on AI coding tools that generate more flawed code than ever.

Hopefully, there will come a day soon when AI coding tools generate higher-quality code, but in the meantime, DevSecOps teams should prepare for the worst. Cybercriminals are now also adopting AI tools with an eye toward not only discovering more vulnerabilities but also creating the code needed to exploit them in a matter of minutes. As such, the number of zero-day vulnerabilities that DevSecOps teams will be required to remediate as quickly as possible is about to dramatically increase.

December 18, 2025
Don’t Reinvent the Wheel: A Developer’s Guide to AI Reusability

Every great innovation brings on new challenges, and AI is no exception. As technology leaders instruct their workforces to default to using AI in their day-to-day tasks and as AI workflows become increasingly critical to software engineering practices, a familiar challenge persists: reusability.

There are libraries, packages and shared components available for reuse with traditional software, but developers are currently being tasked with building AI workflows from scratch. Having multiple developers within one organization writing the same AI prompts and workflows is inefficient, wastes resources, can result in inconsistent outcomes, and potentially hinders wider adoption of AI.

The solution is applying standard software engineering principles to AI: Build once, reuse everywhere. In this post, we will cover some of the ways we have been thinking about the challenge of AI reusability at GitLab.

The Problem With Current AI Development Practices

Whether it’s a chat experience, a remotely executed AI workflow, or local code suggestions, developers have many opportunities to bring AI into their work.

As organizations encourage the increased use of AI in daily workflows, developers have largely been left to figure out how to utilize AI on their own. Broadly, there is very little guidance available on what works well in the context of an organization’s development practices.

As detailed in the soon-to-be-published 2025 GitLab DevSecOps Report, 85% of DevSecOps professionals agree that “Agentic AI will be most successful when implemented in a platform engineering approach.” When AI can be packaged and easily consumed by developers in a self-service way, it will help developers quickly onboard to AI experiences, share best practices, and maintain AI workflows via strong developer communities.

Organizations will be rewarded for their investment in this area with saved time for their development teams, cost savings from optimizing AI workflows, and the ability to deliver better results faster for customers. But what does it actually mean to make AI reusable?

Key Considerations for Making AI Reusable

There are several key considerations to keep in mind when creating reusable AI workflows. Let’s walk through the process of creating a reusable workflow using a common developer productivity issue as an example, and use this process to help developers fix failing pipelines more efficiently.

Step 1: Identify time-consuming developer workflows

One of the most common challenges developers face when using any CI/CD tool is the need to fix failing pipelines. This is a time-consuming task that requires looking through CI/CD logs, understanding the pipeline configuration, and iterating on potential solutions.

Step 2: Provide the appropriate context and permissions that will help focus AI models

By providing AI with lowest-level access to code repositories and CI/CD logs, along with a detailed system prompt, testing can be conducted to see how well AI handles different kinds of pipeline failures.

Step 3: Verify how well AI handles the task

As initial testing is conducted, access, context, tools, and prompts can be tweaked to produce better fixes. After testing AI’s ability to address pipeline failures, the next consideration is ensuring anyone can use this approach consistently.

Step 4: Define what hardware and tools can execute the AI workflow

What hardware is available to run this AI workflow reliably and with easy access? A common pattern is to use CI/CD jobs to remotely execute AI workflows, providing consistent tooling, prompts, and context.

For this particular workflow, CI/CD jobs enable the cloning of code repositories, installation of tools on underlying hardware, issuing API calls to AI models, and providing access tokens that grant the necessary permissions to suggest pipeline fixes back to a code repository. While CI/CD is one mechanism for executing AI workflows, organizations have many hardware options to consider.

Step 5: Version the workflow

Versioning becomes critical once the workflow is operational. For the pipeline fix workflow, consider what needs to be tracked: Which version of the AI model produces the best results for different failure types? What specific system prompt led to improvements in fix accuracy? Which tool versions are installed in the CI/CD environment?

Each tool used, the AI model version, hardware specification, system prompt, and even sample context data should be versioned together as a cohesive unit. This ensures that developers get a tested and reliable combination of all these elements.

Discoverability and Community

Once you have a strong process in place that others can benefit from, the next step is to make it findable. One suggestion is to apply an old idea to this new AI context: Software catalogs.

The idea behind a catalog is to make it easy for developers to search for what already exists. This should be the first step any development team takes before creating something new. As the old saying goes, let’s not reinvent the wheel.

Software catalogs have been a popular tool for promoting reusability across various areas of software development. For example, organizations have leveraged service catalogs to promote the reuse of APIs, CI/CD catalogs to share CI/CD best practices across the organization, and configuration catalogs to share infrastructure setups.

AI workflows need this same experience. Having a central location for all existing organizational information is crucial for facilitating AI adoption. It also helps promote community-driven development. Open source and inner source practices are not going to immediately change as a result of AI. When AI workflows are available to view and use, developers will contribute to improving the experience for themselves and others.

Whether you use a catalog experience or another way of centralizing AI workflows, it is important to think about how developers will find and contribute to already existing ideas for AI.

Treating AI workflows as reusable engineering assets rather than one-off implementations will accelerate AI adoption and improve consistency across development teams. Standard software engineering practices (modularization, packaging, versioning, and community contribution) apply directly to AI workflow development. Just as it is important to encourage AI usage throughout an organization, organizations must invest in frameworks that make it easy to discover and contribute to existing AI innovations.

October 24, 2025
We Are Living in an Ephemeral World

We are lucky to live and work in the times that we do. Oh, we have our challenges, and I talk about them a fair amount here on these pages. But the things we can do in IT today have not been possible in the past, and the change isn’t over. Soon you will be able to relegate pretty much all of the busywork of IT to automated systems, Note that I did not say “AI/ML”–some of that automation will be, but we throw the term around too much right now, and not all automation will be based on AI/ML. In fact, quite a bit of the best automation is simply rule-based systems that we finally have things standardized enough to write up. And I intend to talk specifically about automation that is not AI/ML today.

We have reached the point in DevOps where we can automate the entire build/release process using containers. The CI tool, running in a container, can spawn a container that performs the build. Then, when it is done, if it passed, it can spawn another container to run tests, do security scans, etc. Finally, the product can be promoted and released … in a container. Human involvement is only required for approvals and then only for organizations that want checkpoints on the way to production (which is definitely most but not all of us).

If you take the totality of what is going on out there in DevOps, it is finally catching up to DevOps. The biggest issue will be making it efficient and doable for the DevOps team. To date, by focusing on DevOps, teams have been able to avoid the simple fact that complex deployments on infrastructure that spans environments and uses external resources is hard. By keeping the DevOps side simple (or not part of the DevOps process), developers can crank out code faster, facilitated by DevOps tools and Agile methodologies, and operations can continue to wrangle the beasts of networking, storage, etc. to get the app running in production. Once ops has completed the process, then it can be automated based on steps taken.

But we now have Software-Defined Everything ™ combined with containers. That means that for many–though not anywhere near all–applications, a commit that updated a constant in a single source file can spawn the entire process in iterative containers all the way through release. That is very cool, and we should take a second to appreciate how far we’ve come in a short time.

Then we need to talk about those worker containers. They need a ton of centralized logging and reporting. Spinning them up, letting them run and then automatically destroying them is fine—as long as the organization has access to the information it needs to review and analyze the results. In-application tooling will cover the released product and even the test environment, but not an ephemeral build process. By not keeping a ton of build tools running all of the time, the enterprise is, by definition, more secure—the blast radius is reduced if build tools are only available when they’re active, and logging of who/what kicked of a build is kept. But don’t forget the reporting. At build time, our tools know exactly which error failed a build; the container needs to submit a ticket before being destroyed or log heavily. I say, “Always create a ticket,” but I’ve worked in enough environments to know that your reality may not make that possible. As long as notifications occur, it doesn’t really matter how they occur.

So crank it up; start super-automating. Tool up those build environments, then make them into disposable container instances. Others have been doing this for a while, so there is help available for setting it up, but it is just now taking off, so it is a good time to dive in. And keep rocking it. How the apps are built and deployed is only important in the sense that you are driving the company forward. Keep doing it.

February 8, 2023
DevSecOps Tools: Hot Air Ahead

I, like most of you, don’t like hardcore marketing that hinges its statements on “Well, that’s technically true…” I also am not a fan of talking heads that spew predictions about the future. Sure, they’re right sometimes; that’s because we have so many people pontificating that random distribution means some will be correct. I am bringing all this up to warn you that I (basically a high-tech talking head) am about to talk about tools, the future of tools markets (one in particular) and what I think should/will happen.

Sometimes, talking about the future of a given tech is done to make a name for yourself. I don’t play that game. My goal is simply to say, ‘This is what I would like to see, and why I would like to see it.’

Enough spewing—let’s talk about DevSecOps tools. I jotted down this topic a while back when I touched briefly on it, and my ideas firmed up while working on a recent project.

Let’s start easy. If you are not using what we currently call DevSecOps tools in your DevOps toolchain, go get them set up. Go ahead, we’ll wait. It’s that much of a no-brainer that we’ll sit here while you choose, purchase and install your choice. Seriously. “Here is a tool that will make development more secure and make developers more productive.” Go install it now. Choose what functions you want to use and work them into your toolchain.

But don’t get too married to your vendor. Because for the very same reasons I just told you to go install them, I will say I don’t think they should be a standalone market. Here is a toolset that plugs into the IDE on one end, and runs stand-alone, integrated with CI/CD on the other. It is DevOps in many ways. And while code scanning is inarguably a security function, the spirit of DevOps overall is “Who cares?” Using these tools shifts quite a bit of security functionality left and also warns about bad coding practices. Note I did not specifically say insecure coding practices, though those are covered. I said bad coding practices. The largest of these vendors will let you know things like, “Hey, you sent that variable to this function and then never used it. Are you sure?” or “This loop looks like it never exits. Are you sure?”

It should be, and I predict will be, part of the DevOps process. In my dream world, the functionality would get split and some would end up in IDEs, while the rest would end up in testing tools or CI tools. But that’s not normally how markets get split up when there are established vendors. Even though you can feel the difference in the functionality (a bunch of them plug right into the IDE; the rest don’t), it won’t get split up because existing markets generally merge through acquisition. So we’ll have to see how things fall out, but I’m betting on CI/CD vendors or system-wide security vendors moving into this market. Indeed, companies with a SOC will likely find these vendors appealing because most of them also operate SOCs for the dynamic scanning part of the system.

Still don’t have DevSecOps installed? Go now. Choose a vendor.

Because I’m being so forceful about telling you to install one of these toolsets, I’ll state very clearly: At the time of this writing, I do not have any kind of relationship with any vendor in this space. I say this because I use the tools and strongly believe that the pain points they bring as a layer in development are very much made up for by the benefits they bring to the application.

And keep rocking it. This will just make your systems more stable, and the merges (that I see as inevitable, but is actually only a possibility) you can worry about when they come along.

April 13, 2022
How Log4j Becomes a Serious DevOps Problem
The recent discovery of the Apache Log4j vulnerability has wide-ranging implications for anyone who develops software, especially for those in the DevOps realm. What’s most troubling about the vulnerability (CVE-2021-44228) is how prevalent the use of Log4j is. The vulnerability is reported in a vast array of applications and directly impacts numerous Apache projects, including Druid, Dubbo, Flink, Flume, Hadoop, Kafka, Solr, Spark and Struts. There are also numerous Cisco programs impacted by the vulnerability. The list of impacted applications and libraries seems to be almost infinite, extending to Elastic LogStash, GrayLog2, Neo4J, Steam, Twitter and even the VMware Tanzu family of programs.

Simply put, any application that uses Log4J for logging and tracing is subject to the identified family of attacks known as Log4Shell. Those attacks prove easy to exploit and can be used to take control of vulnerable servers.

Why DevOps Practitioners Should be Concerned

The world of DevOps is all about reiteration, where features and improvements to applications are slipstreamed into production environments. To accelerate development, the QA process is usually limited to the most recent changes.

In other words, developers, via their pipelines, can often establish a baseline of quality and then speed up their CI/CD pipelines by testing only what has changed since the last iteration of the application. This process ensures an acceptable level of quality without introducing what are perceived to be unnecessary steps.

However, those processes do not take into account newly discovered flaws in older APIs and libraries, meaning that those flaws could telegraph into deployed applications and leave DevOps teams completely unaware of the impact and possible disruption. Detecting flaws after an application is deployed is like putting the cart in front of the horse.

Further complicating the situation is that many developers lack a well-defined and well-maintained software bill of materials (SBOM), which means developers may be unaware of the components and/or libraries being used in a deployed application.

Without an SBOM, it becomes increasingly difficult to remediate an issue with an application—especially if developers are unaware of the issue to begin with.

Where Should Responsibility Lie?

More often than not, vulnerabilities introduced into applications become a game of finger-pointing, where developers blame library suppliers or infosec staffers, and infosec blames developers for not performing due diligence on the components they are selecting to incorporate into their applications.

Of course, finger-pointing only adds to the angst and delays the process of remediation and does nothing to determine where the responsibility for detecting and remediating vulnerabilities lies. DevOps teams need to put these squabbles aside and establish a process that deals with unintentionally introduced vulnerabilities. What’s more, DevOps teams need to invest in DevSecOps to make sure that vulnerabilities are detected and remediated as quickly as possible.

To avoid the potentially massive disruption that a vulnerability like Log4Shell can cause, those running DevOps should consider:
- Creating and maintaining an SBOM
- Deploying automated tools that scan for discovered vulnerabilities
- Automatically comparing the SBOM against vulnerabilities
- Including DevSecOps processes within their CI/CD pipelines
- Frequently testing applications for flaws
- Coordinating with cybersecurity personnel when a flaw is discovered
- Patching frequently
With more and more vulnerabilities discovered on an almost daily basis, DevOps teams must be ever vigilant about what components are incorporated into their applications. What’s more, with the increased use of low-code/no-code tools and integrated development environments (IDEs), DevOps will also need to consider if those tools use other libraries that can become compromised.
December 20, 2021
DevSecOps for Security and Safety-Critical Software Development
One of the most effective software development practices for safety-critical software is DevSecOps. Put simply, DevSecOps automates development and security processes to ensure the security and reliability of software. Here, we explain what you need to know about DevSecOps.

What You Need to Know About DevSecOps Automation

DevSecOps is a software development practice that automates and shortens feedback times to ensure secure software development. In general, safety-critical software development requires compliance with industry-specific, functional safety standards — each of which has its own set of core requirements to help you develop software that is safe and secure. While each standard’s guidance is unique, they all require a controlled, reliable, repeatable and automated set of delivery processes to demonstrate compliance. DevSecOps provides just that.

How DevSecOps Automation Works With CI/CD Pipelines

An important part of DevSecOps automation are CI/CD pipelines. In general, CI improves the quality of your codebase by breaking up tasks into smaller, more manageable chunks as well as by performing frequent code integrations. By using CI, you are able to identify problems sooner, easily encourage more modular changes to your code, automate tasks and detect issues quickly.

The Benefits of DevSecOps Automation

While you and your team may experience different benefits of DevSecOps, in general, the most common benefits of DevSecOps include the following:
- Lowered development and operation costs. · Shortened development cycles.
- Increased release pace.
- Improved detection of software vulnerabilities and errors.
- Reduced amount of failures and rollbacks associated with deployment.
- Reduced amount of time to recover from a software development failure.
What DevSecOps Automation Tools Should You Use?

By using a DevSecOps tool to automate your processes, you ensure your software development process is free from software vulnerabilities and errors. The most common DevSecOps tool is a static application security testing (SAST) tool. A SAST tool automates your vulnerability detection processes, eliminates identified vulnerabilities, increases the pace of development and reduces the amount of disruption to your software development process.

To read more, please visit: https://www.perforce.com/blog/kw/devsecops-automation-safety-critical-software
January 11, 2021