devopsy.kinsta.cloud

Tag: devsecops

Why DevSecOps Isn’t a Thing Yet
DevSecOps has been promoted as the future of secure software development, integrating security directly into the DevOps lifecycle. However, despite its promising potential, many organizations have yet to fully embrace and implement DevSecOps. The key challenges lie in cultural resistance, toolchain complexity and misalignment of security priorities.

1. The Culture of Resistance

One of the biggest obstacles to DevSecOps adoption is the cultural gap between development, security, and operations teams. Traditional security teams operate with rigid controls, which often slow down the fast-paced DevOps model. Developers prioritize speed and innovation, while security mandates often introduce bottlenecks.

Key Issues:
- Lack of security awareness among developers.
- Resistance from security teams to shift towards automation.
- Misalignment of objectives across teams.
2. Tooling Complexity and Integration Gaps

DevSecOps requires seamless integration of security tools into the CI/CD pipeline. However, many organizations struggle with:
- Fragmented Security Toolchains: Security tools often function in silos, creating complexity when integrating with DevOps workflows.
- False Positives and Alert Fatigue: Automated security tools generate numerous alerts, making it difficult to prioritize real threats.
- Lack of Standardization: No single universal DevSecOps framework exists, making adoption inconsistent across organizations.
3. Security as an Afterthought

Many organizations still perceive security as a separate phase rather than a continuous process. Security is often introduced late in the development cycle, leading to:
- Costly Late-Stage Fixes: Addressing vulnerabilities after deployment increases remediation costs.
- Compliance-Driven, Not Security-Driven: Many companies implement security practices just to meet regulatory requirements rather than proactively enhancing security.
- Limited Executive Buy-In: Leadership often prioritizes feature development and time-to-market over security investments.
4. The Need for Skills and Training

The rapid evolution of DevSecOps demands upskilling across development and security teams. Organizations struggle to find professionals who are well-versed in:
- Secure coding practices.
- Automation of security checks.
- Cloud-native security tools and methodologies.
Making DevSecOps a Reality

For DevSecOps to become mainstream, organizations must:
- Foster a security-first mindset across all teams.
- Invest in automation and security tools that integrate seamlessly.
- Provide continuous training to bridge skill gaps.
- Align security objectives with business goals.
While DevSecOps remains an evolving practice rather than a widespread standard, organizations that proactively address these challenges can pave the way for a more secure and agile development lifecycle.
June 26, 2025
AWS Extends Cloud Security Reach to Include DevSecOps Tools to Scan Code

Amazon Web Services (AWS) this week made Amazon Inspector, a code scanning tool for surfacing vulnerabilities that is designed to be natively integrated with GitHub and GitLab platforms, generally available.

Announced at the AWS re:Inforce 2025 conference, Amazon Inspector combines a static application security testing (SAST) tool for analyzing application source-code with a software composition analysis (SCA) tool for evaluating third-party dependencies and an ability to scan infrastructure as code (IaC) for valid definitions.

Findings from these scans are then surfaced both in the Amazon Inspector console and within the source code management platform as fast feedback for the developers.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at The Futurum Group, said the expansion of the DevSecOps capabilities provided by AWS into code, dependencies, and IaC enable a critical ‘shift left’ for cloud security, fundamentally embedding vulnerability management earlier into the development lifecycle. That unified approach addresses a long-standing challenge for DevOps teams by accelerating feedback and fostering truly secure-by-design applications, he added.

Additionally, AWS also revealed it has made available under an open source license a software package, dubbed @verifiedpermissions/authorization-clients-js, that enables developers to implement authorization in Express.js web application APIs in minutes. That approach reduces the custom authorization code that developers would have previously needed to create on their own.

Finally, AWS demonstrated how it is internally using Amazon Q Developer, an artificial intelligence (AI) agent framework, to identify vulnerabilities in code as it is being developed.

George Argyros, applied science manager of AWS, told conference attendees Amazon Q Developer makes it possible to “squash bugs” early in the application development process in a way that ultimately serves to improve the quality of the code being created. The overall goal is review code at the time a pull request is made and then surface recommendations to mitigate any issue, with Amazon Q Developer also being used to create and test any patch required.

It’s not clear how widely the DevSecOps tool and platform being provided by AWS have been adopted, but it’s clear the cloud services provider is now moving well beyond securing infrastructure. It’s still the responsibility of organizations to secure the applications deployed on the cloud, but AWS is making the tools and services needed to achieve that goal more accessible.

Hopefully, there will even come a day soon when application development teams are routinely using AI tools to prevent vulnerabilities and misconfigurations from being created in the first place.

In the meantime, however, DevOps teams need to be sure to review the code being generated by AI tools that have been trained using examples of code that is of varying quality. In one instance, that code might be better than what some developers might write on their own. In other cases, segments of code with known vulnerabilities might have been copied multiple times over. In fact, about the only thing that is for certain is that there will soon be more code than ever to scan and review as developers continue to lean on AI tools to create code that they are becoming less inclined to write themselves.

June 18, 2025
Merging Business Logic and DevOps

I remember recently sitting with one of our application owners, trying to figure out why automation initiatives felt perennially stuck. Everyone on the infrastructure side had scripts that handled tedious tasks, and our development teams had pipelines that delivered code faster than ever — yet executives remained stuck on why automation wasn’t creating the kind of business impact they had expected. The answer was simple: We had never articulated our work in terms of the goals they focus on. In other words, I saw that bridging the gap between DevOps and business logic was the way past the buy-in ceiling.

Where DevOps Hits the Business Wall

DevOps started as a way to merge the needs of developers and infrastructure engineers so code could flow from commit to production in a seamless pipeline. That approach dramatically cut the time it took us to deploy new features, and it reduced environment inconsistencies that usually caused failure. Those early gains were dramatic — fewer manual handoffs, more frequent releases and far less friction between dev and ops.

Yet I kept noticing that DevOps alone didn’t help me answer bigger questions like, “How does this release improve our margins?” or “Where do we see profitable opportunities for automation?” Developers focused on bug fixes and features, and infrastructure folks prioritized stability and performance. Neither side was accountable for tying these deployments to corporate growth or profit goals. The impact is there. A study examining DevOps implementations found that organizations that embedded business-facing roles into DevOps practices saw measurable financial benefits, including revenue increases and faster time-to-market, reinforcing the importance of aligning development efforts with corporate objectives.

That misalignment is also what prevents organizations from moving beyond departmental automation into business-driven outcomes. It’s one thing to automate code deployments; it’s quite another to automate an entire client onboarding process with cost controls, compliance reviews and marketing triggers baked right in.

The Business Logic Layer

Rather than hoping that new features alone — fancier CI/CD tools, or better infrastructure monitoring — will deliver a business advantage, it means threading revenue goals, product metrics, compliance thresholds and even marketing feedback loops into the same pipeline that developers use. When the pipeline can incorporate these upstream needs, a new product launch automatically triggers finance approvals, governance checks and environment provisioning without manual sign-off. That’s when my scripts stop looking like pure tech solutions and start looking like measurable ROI. This alignment is what separates DevOps as an efficiency tool from DevOps as a revenue enabler.

The Critical Role of Application Owners and Product Managers

An application owner is usually close enough to the code to understand how it’s built and close enough to the business to know why it’s built. The same is true of product managers who have to balance feature sets with market demand. They are the natural bridge between a pure DevOps mindset and the more complex perspective an executive might have.

I’ve seen these roles act as the translation layer. They take business requirements and shape them into tasks that developers can automate. They also bubble up constraints — like compliance or security standards — that infrastructure teams enforce. When these roles gain a say in how the pipeline itself operates, we can stop limiting our automation to low-level tasks and start automating real business workflows. Companies that have taken this approach have reduced financial processing errors by 80%, demonstrating the power of automation when applied beyond deployment workflows.

Automation as a Business Force Multiplier

Once product and application owners map out key business outcomes, we can embed them in DevOps pipelines. Many of us start with a string of scripts that manage simple chores like environment provisioning. That’s Stage 1 or 2 in the typical automation maturity model. By the time we’re hitting Stage 4 or 5, an entire product release or a client onboarding becomes a single automated workflow. It touches CRM entries, compliance gating, network segmentation, and deployment to production without anyone having to do it manually.

I’ve watched this reduce wait times for new product deployments from weeks to hours, save operating costs by ensuring we’re not over-provisioning resources, and improve a sales team’s close rates because they can promise faster delivery. Without strong ties to business logic, those same DevOps practices remain restricted to IT cost savings. With business integration, they become revenue and margin drivers. BMW’s process automation efforts in their supply chain demonstrate this impact at scale — shorter production cycles and substantial cost savings directly resulted from enterprise-wide automation.

Empowering Non-Technical Teams

It’s tempting to assume that only developers or infrastructure engineers benefit from pipeline insights. When business logic provides a bridge to marketing, HR, finance, or support teams, they suddenly see ways to automate their own workflows — like a marketing campaign that syncs with staging releases to gauge new features for promotional materials, or an HR system that automatically spins up application access for new hires.

Some of the hardest transitions happen here because non-technical teams may not see their goals as targets for automation. I show them that well-designed DevOps toolchains can be configured to automate tasks in plain language. If finance has to do an audit or a compliance check, we can embed it as a pipeline gate that no new product feature can bypass. That standard keeps us secure, and it keeps finance engaged in real-time. Organizations that introduce automation broadly across teams not only see efficiency gains but also a significant boost in employee satisfaction, with 65% of knowledge workers crediting automation for reducing stress and improving workflows. And in this way, it’s only by adopting the enterprise-wide language of business that DevOps can deliver its full value.

June 17, 2025
How to Embed Security Into Enterprise DevOps Pipelines
Security isn’t something you bolt on at the end. Today, if you’re pushing code fast, you need to make sure it is secure from the start. Enter DevSecOps.

It is the mindset (and practice) of baking security right into your development and deployment workflows — not treating it like an afterthought. This approach helps teams catch issues early, reduce risk and release confidently.

Think about it: With supply chain attacks, application programming interface (API) breaches and open-source vulnerabilities making headlines every other week, ignoring security isn’t just risky — it is reckless. For enterprises, the stakes are even higher: Customer trust, brand reputation and compliance are all on the line.

This guide will walk you through how to embed security into your DevOps pipeline without slowing things down.

Current Challenges in Enterprise DevOps Security

Embedding security into enterprise DevOps isn’t equal to slapping on a new tool. It is about rewiring how teams work — easier said than done. Here are some of the biggest blockers:
1. Security is Still a Silo
In many organizations, developers ship features, the operations team keeps things running, but security? They are the team that says ‘no’. That is a problem. Security needs to be in the room from the start, not chasing bugs after the fact.
1. Manual Reviews Don’t Scale
Security teams can’t keep up with fast-moving pipelines. When reviews are manual and slow, they either get skipped or slow everything down.
1. Open Source = Open Risks
Modern apps rely on a ton of third-party libraries. While that accelerates things, it also opens the door to vulnerabilities — ones you didn’t write (and maybe didn’t even know you had).
1. Developers Aren’t Trained in Security
Most developers aren’t taught how to write secure code. That is not a knock — it is just reality. Without the right support, they will prioritize speed over security every time.
1. Inconsistent Tooling and Policies
One team might use Snyk, another uses something else. Policies are unclear. Tooling is fragmented. The result? Gaps, which attackers love to capitalize on.

Start With a Security-First Culture

Before you automate anything or add new tools, take a step back. Security is a mindset shift more than anything. If your team sees security as someone else’s job, no tool is going to save you.

Everyone, from product managers to QA testers, should be aware of the basic security risks associated with their work. Start small: Run threat modeling sessions during sprint planning or include security checks in code reviews. Every team needs a go-to person who gets security and can help others level up. These ‘security champions’ don’t replace your security team — they extend it. Think of them as the bridge between development and security.

Moreover, enterprise security shouldn’t be a finger-pointing game. Encourage open conversations about enterprise network security, vulnerabilities, incidents and fixes. Blame-free retros make it easier to learn and improve. Celebrate developers who catch a risky bug early or refactor insecure code. If you reward only for speed, you will never get security baked in.

Secure the CI/CD Pipeline Itself

You can’t secure the code if your pipeline is wide open. A misconfigured continuous integration and continuous delivery (CI/CD) system is often the easiest way into your production environment. To lock it down, use role-based access control (RBAC). Only give people and services the permissions they actually need. No more ‘admin by default’.

Stop hardcoding secrets. Use a secure secrets manager like HashiCorp Vault, AWS Secrets Manager or Doppler. Rotate credentials regularly. Your pipeline configuration (GitHub Actions, GitLab CI, Jenkinsfiles, etc.) should live in version control, like your app code. That means pull requests, code reviews and change tracking.

Also, keep a record of who did what and when. Logs can help you detect suspicious activity and make incident response 10x easier. Pin versions in your CI pipeline and avoid auto-pulling the latest from unverified sources. That ‘update’ might ship more than you bargained for.

Automated Security Testing in Every Stage

Automation helps catch issues early, often without slowing your pipeline down. Here is how to embed security checks across your DevOps stages:
- Pre-Commit: Use Git hooks and tools like Gitleaks or TruffleHog to scan for hardcoded secrets before code ever hits your repo.
- Build Stage: Run static application security testing (SAST) tools during build to catch insecure code patterns. Tools such as SonarQube, Semgrep or CodeQL work great here, and many integrate directly with CI tools.
- Dependency Stage: Use software composition analysis (SCA) tools to scan third-party libraries for known vulnerabilities. Tools such as Snyk, OWASP Dependency-Check or GitHub Dependabot are solid picks.
- Test Stage: Use dynamic application security testing (DAST) to probe your running app for issues such as XSS or SQL injection. Add fuzzing tools to throw unexpected inputs at your APIs and see what breaks.
- Deploy Stage: If you are deploying infrastructure as code (IaC), tools such as Checkov or tfsec can flag misconfigurations before they go live. Scan your container images with tools such as Clair, Grype or Docker Scout to catch operating system (OS) and package-level vulnerabilities.
Policy as Code: Enforcing Security via Automation

Policy as code lets you define security rules in code and enforce them automatically — no meetings and no guesswork. So, instead of writing policy documents that no one reads, write rules as code. For example:
- ‘All S3 buckets must be encrypted’
- ‘No hardcoded secrets in source code’
- ‘No privileged containers in production’
You can version-control these policies just like your app code. Open Policy Agent (OPA) lets you enforce rules across CI/CD, Kubernetes, Terraform and APIs. HashiCorp Sentinel works well with Terraform and Vault for enforcing infrastructure policies. Tools such as Kics, Checkov and Regula offer similar checks tailored for infrastructure as code.

Furthermore, integrate the following policy checks into your CI pipeline:
- Block deploys if certain security rules fail
- Require approvals for high-risk changes
- Ensure policy compliance before code hits production
Policy as code also makes compliance easier. You will have a versioned, testable and enforceable record of your controls — excellent for SOC 2, ISO 27001, HIPAA and others.

Monitor and Respond in Production

Even with all the pre-release checks in place, stuff slips through. That is why runtime security matters. You need to know when something weird happens — and act fast. Use tools such as Falco, Sysdig or Datadog Cloud SIEM to detect suspicious activity:
- Unexpected network connections
- Container breakout attempts
- File system tampering
Set alerts that mean something. Avoid alert fatigue. Then, pipe security data into tools your teams already use:
- Prometheus + Grafana for metrics
- ELK stack or OpenSearch for log analysis
- PagerDuty or Slack for instant alerts
Don’t silo your security data. The more visibility developers and the operations team have, the faster they can respond. Also, when something does go wrong, you need a plan. Automate the basics (log collection, alerts), but also train your teams on what to do.

Measure and Improve: KPIs for DevSecOps

Speaking of security data, you need to create a feedback loop. You need to know if your security efforts are making a difference. Here is what to track:
- Mean Time to Remediate (MTTR): How fast are you fixing vulnerabilities after they are found? Shorter MTTR — healthier pipeline. Aim to detect and fix issues in hours or days, not weeks.
- Percentage of Builds Passing Security Checks: Are security scans breaking your builds? That is not always bad, but if most builds are failing, something is off. Either your code quality is low, or your policies are too strict.
- Vulnerability Age: How long are known vulnerabilities sitting around before they are resolved? If issues are growing stale in your backlog, that is a sign they are not being prioritized.
- False Positive Rate: Too many false alarms — alert fatigue. If your team is ignoring alerts, that is a security risk. Tune your tools to highlight what actually matters.
- Security Coverage Across Stages: Are you running tests at every stage? You want full coverage — code, dependencies, infrastructure and runtime — not just a single SAST scan.
- Compliance Readiness: How quickly can you demonstrate compliance with SOC 2, HIPAA or ISO standards? The more automated and documented your pipeline, the easier this becomes.
Use these metrics not to blame, but to learn. Run blameless retros, find the root causes and make continuous improvements. DevSecOps is a journey, not a destination.

Wrapping Up

Security doesn’t have to be a roadblock. When implemented effectively, it accelerates progress. It gives your teams confidence to ship faster and gives your customers confidence to trust what you have built.

Embedding security throughout your DevOps pipeline — from planning to production — is not just checking boxes. It helps in reducing risk, improving code quality and building a culture of accountability.

Remember, DevOps without security is just speed with risk. Now is the time to shift left, automate smart and build security into everything.
June 17, 2025
JFrog Extends Alliance With NVIDIA to Secure AI Software Supply Chain

JFrog and NVIDIA today announced they have expanded the integrations between their software development platforms to now include the Enterprise AI Factory, a set of frameworks and blueprints for building artificial intelligence (AI) applications.

As a result, software artifacts created using the NVIDIA Enterprise AI Factory can be housed in the JFrog Software Supply Chain Platform. The JFrog ML platform, meanwhile, provides a registry for managing the lifecycle for building and deploying AI models by enabling versioning, provenance tracking, model promotion, and enforcement of security policies.

Additionally, JFrog metadata and promotion workflows ensure immutable AI artifacts can only move between stages when all quality, security, and legal checks have passed. AI models can also be cached, continuously monitored and updated to align with regulations. Critical patches and AI model updates can also be centrally managed similarly.

Finally, the JFrog ML platform also enables application development teams to enforce role-based access control (RBAC) to ensure that access to AI artifacts is traceable for compliance purposes.

Collectively, those capabilities ensure all AI software is signed, validated and approved before deployment.

Kristian Taernhed, senior technical alliance manager at JFrog, said the overall goal is to provide a repository that can be deployed in an on-premises IT environment to provide DevSecOps teams with a platform to manage all their software artifacts, including AI agents and models. That capability, for example, enables organizations to leverage scanning tools to prevent malicious AI models from being inadvertently incorporated into an application, he added.

Locking down the software supply chain used for building AI applications is crucial not just for organizations concerned about highly regulated industries but also in countries that have developed policies pertaining to how AI applications are developed, also known as Sovereign AI, he added.

Specifically, Sovereign AI mandates typically require AI data to remain within specified geographic or organizational boundaries and for strict controls across the AI software supply chain to be enforced.

It’s not clear to what degree machine learning operations (MLOps) workflows used to build AI models are being integrated into DevOps workflows, but for all software engineering purposes, those models are simply just another type of artifact that needs to be integrated into a build. Going forward, just about every application being built is going to have some AI capability, so the number of AI models that will need to be incorporated into a DevOps workflow is only going to continue to increase.

The bigger challenge may be melding the cultures of the data science teams that typically build AI models with the DevOps and platform engineering teams responsible for building and deploying software.

In the meantime, there will be no shortage of platforms for building AI models that will need to be integrated into DevSecOps workflows. Some organizations may be able to standardize on a few, but given the pace of innovation, the number of platforms being used to build AI models continues to increase. Most data science teams, much like their DevOps counterparts, prefer to retain control over the tools and platforms used to build those AI models, so enforcing a platform standard across every data science team is in the short term likely to be a challenge.

The good news, of course, is that with each integration, the level of expertise attained should, hopefully, make the next project that much easier.

June 11, 2025
DevEx Got You This Far: What’s Next for True DevSecOps Maturity?

The journey toward integrating security into the fast-paced world of DevOps has seen significant strides, largely thanks to a much-needed focus on the developer experience (DevEx).

Collectively, the AppSec community and industry have moved mountains in making security tools less intrusive, integrating them into developer workflows, and acknowledging that developers need security as a help, not a hindrance. A focus on DevEx has been crucial, acting as the bridge to bring security considerations earlier into the development lifecycle while simultaneously enhancing the developers’ daily work.

The numbers don’t lie: Checkmarx’ recent DevSecOps Evolution 2025 report reveals that a majority of the organizations we surveyed—58% to be exact—are at Stage 2 maturity, a transition stage primarily focused on DevEx: They’ve integrated tools into IDEs, offer formal training, and the relationship between security and development teams is generally positive. While these developments signify important progress, this DevEx-focused stage represents a critical foundation rather than the ultimate destination in achieving mature DevSecOps.

DevEx Isn’t the Destination

Organizations haven’t yet achieved true DevSecOps maturity. They haven’t yet embedded security through shared culture, governance and aligned goals.

And while developer experience is essential, it’s just one brick of the DevSecOps foundation. To achieve the ultimate goal—high-performing, secure code delivered at the pace of business—organizations need to move beyond DevEx to a true culture of shared responsibility and trust.

Despite better tools and training, developers still report spending a significant chunk of their week—often over 17 hours—on security tasks. Trust in tool results is often hampered by false positives impacting velocity, and a lack of shared goals that align development and AppSec priorities means security can still feel like a separate concern rather than a shared objective. We’ve improved the experience; but haven’t fully embedded security seamlessly and at scale.

The Scale – and Stakes – Are Growing

The need to mature beyond DevEx is especially urgent given the accelerating complexity and scale of modern application development. Enterprises are managing sprawling codebases and adopting tools that increase both speed and risk. Checkmarx alone scans over 450 billion lines of code every month, and that figure is only rising.

At the same time, the software supply chain is expanding at an unprecedented pace: approximately 700,000 new NPM package versions are introduced monthly, each one a potential point of exposure.

Add to this the growing adoption of AI-assisted coding tools and agentic AI systems that generate or modify code autonomously, and the attack surface multiplies further.

On the other hand, development productivity requirements have never been higher, with organizations tracking DORA metrics and looking for AppSec solutions like Checkmarx’ that deliver on security while optimizing MTTR and other DORA metrics.

Achieving truly mature DevSecOps—Stage 3, where only 30% of organizations currently reside—requires moving beyond just making security palatable for developers. It demands a deeper, more strategic integration built on shared culture, robust governance, trusted automation, and aligned success metrics.

Checkmarx’ Five Pillars of DevSecOps Maturity

At its heart, DevSecOps is a cultural evolution. It’s about merging the “move fast” ethos of development with the “protect everything” mandate of security to achieve a common goal of delivering secure, high-performance code at the speed the business requires. To progress from Stage 2 (DevEx-focused) to Stage 3 (Mature DevSecOps), organizations need to build on their DevEx foundation with five key elements:

1. Shared Metrics

You can’t improve what you don’t measure, yet our research shows a surprising lack of consensus on DevSecOps metrics. While many organizations we surveyed track top vulnerable applications (52.1%) and mean time to detect vulnerabilities (51%), only 28.3% measure mean time to remediate—arguably the most critical metric for balancing security and velocity.

True DevSecOps maturity requires security and development teams to align shared metrics that measure how effectively they work together, not just how many vulnerabilities they find.

2. Collaborative Governance

In mature DevSecOps, security and development teams jointly establish policies, standards and processes. Our data shows this remains rare—when asked to describe the relationship between security and development in one word, respondents most frequently chose “trust,” “policy,” and “risk,” indicating an evolving but not yet fully collaborative relationship.

For 88% of organizations, the absence of shared metrics, policies and governance suggests security and development teams are aligning but are still struggling to form a fully collaborative governance.

3. Advanced Security Education

While essentially all developers have access to training according to our study, the model needs to evolve. Traditional formal training programs still have value, but the premium on developer time makes standalone training challenging.

Mature DevSecOps organizations are pivoting toward just-in-time training that delivers contextual guidance when and where developers need it. Providing a step further is in-the-moment training with inline feedback from within the IDE, allowing developers to learn while maintaining their workflow.

4. Trusted Automation

Our study showed that one in five (20%) of the organizations we surveyed have no AppSec automation in place. Even among the remaining 80%, adoption of key automation capabilities remains low—only 32% have automated security testing during change management, and just 30% auto-populate security tickets with remediation guidance.

The far-from-optimal adoption rate of automation cannot be attributed to a lack of technological solutions but rather appears as a matter of trust and culture gaps between security and development teams. Without shared governance and metrics, attempts to “automate everything” typically fail because there’s no foundation of trust on which to build automations that both teams will embrace.

5. Velocity-Security Balance

The ultimate goal of DevSecOps is to deliver high-performing, secure code quickly. Yet 66% of developers report that false positives impede their velocity, and 28% say their AppSec teams lack the tools or resources to help them fix security issues efficiently.

Mature DevSecOps organizations recognize that speed isn’t just about how quickly tools scan—it’s about how quickly developers can remediate issues without disrupting their workflow. This requires prioritized, actionable results with clear remediation guidance, not just faster scanning.

The Role of Leadership

Making the transition to DevSecOps takes more than just good tooling—it requires strong leadership. Security leaders must be willing to trade control for collaboration and build systems based on partnership, not policing. Engineering leaders must recognize that security is essential to velocity, not an obstacle.

This shift requires executive buy-in and strategic commitment. It means moving beyond budget conversations centered on compliance and instead investing in the long-term health of your codebase and your teams.

The Road Ahead

As the DevSecOps Evolution 2025 report shows, most organizations are still in the middle of the journey. That’s not a failure. It’s an opportunity. DevEx helped bridge the gap between developers and security, and now it’s time to build the foundation that inspires them to run together. By moving beyond DevEx as the sole focus and embracing these pillars of mature DevSecOps, we can finally embed security seamlessly at scale, achieving the ultimate objective of delivering high-performing, secure code without compromising speed.

The transformation won’t happen overnight. It requires sustained investment in building trust between security and development teams. But organizations that successfully make this journey will gain the significant competitive advantage of more secure and advanced applications built with less friction and lower costs.

As we look to 2026 and beyond, the most successful organizations will be those that move beyond seeing security as just another feature of the development process. Instead, they’ll embrace it as an integral, collaborative aspect of delivering high-quality software in a digital world with ever-rising security risks.

At Checkmarx, we believe the future of software development is secure by design—and it starts with mature DevSecOps. Let’s keep moving forward.

June 9, 2025
Code Signing in the DevOps Era: Silver Bullet or Security Theater?

In my work with global enterprises modernizing their DevSecOps practices, I’ve repeatedly seen a troubling pattern: Organizations implement code signing with good intentions, but without the controls to support it.

In one recent engagement, a team proudly showcased their secure pipeline – automated builds, signed containers and rapid deployments. But during a code audit, we found a private signing key embedded in a script, committed to version control, with no rotation or monitoring. That key had been used to sign production artifacts. If it had been compromised and we couldn’t be sure it hadn’t – an attacker could have shipped malicious code, fully “trusted” by their infrastructure.

This isn’t rare. Code signing is often deployed as a checkbox, not as part of a robust trust framework. And that creates a dangerous illusion of security.

Signed ≠ Safe: The Hidden Risks Behind the Signature

Digital signatures offer authenticity, not invincibility. Several high-profile attacks, including the SolarWinds breach and the more recent XZ Utils incident, show that attackers don’t need to bypass code signing; they just need to operate within its blind spots.

In the case of XZ Utils, malicious code was introduced over time and eventually signed and distributed legitimately. And in SolarWinds, attackers compromised the build system itself. The code was signed, but that didn’t stop the threat. These incidents make it clear that code signing doesn’t prevent compromise; it merely authenticates it.

Failures often stem from poor key management, inadequate revocation mechanisms, or an uncritical acceptance of signatures without examining the broader context. If your systems automatically trust any signed artifact without checking its provenance, you’ve already lost.

Speed vs. Safety: Why Code Signing Struggles in the DevOps Pipeline

In high-velocity environments, security controls are only effective if they blend seamlessly with development workflows. This is where code signing often stumbles. Signing keys may be embedded in scripts, mismanaged in cloud environments, or shared across teams. Developers, under pressure to release quickly, might bypass signing altogether if the process becomes cumbersome.

Worse, many CI/CD systems lack observability, making it difficult to detect anomalous signing behavior. In an era where pipelines are as critical as the code they deliver, this blind spot becomes a liability.

What Code Signing Actually Delivers—and Where It Falls Short

Despite its limitations, code signing still plays a vital role when treated as one part of a broader software security strategy. It must be tightly integrated with secure key storage, revocation processes and post-deployment monitoring. But that’s not enough.

Security leaders must look beyond signatures. Knowing who wrote the code and how it was built matters as much as the fact that it was signed. This means incorporating Software Bill of Materials (SBOMs), establishing build attestation and tracking dependencies in real time. It also means verifying that the code came from a trusted workflow, not just a trusted key.

Ultimately, security doesn’t stop at the signature — it begins there.

What CISOs Should Prioritize: From Signing to Sustained Trust

Code signing only works as part of a disciplined, layered security model. For CISOs and DevSecOps leaders, the challenge is not merely to introduce code signing into the pipeline but to operationalize it securely and sustainably. That means building a trust framework that spans people, process and platform.

Start with secure key management. Signing keys must be protected with the same rigor as encryption keys or credentials. This means hardware security modules (HSMs), cloud-native key vaults and enforcing granular access control — only authorized systems or identities should be able to sign code, and every usage should be logged.

Next, treat signing as a programmable policy, not an optional step. Integrate automated signing into CI/CD pipelines, using policy-as-code tools that enforce when, where and how signing occurs. All build artifacts should pass through this gate, and any deviation should be flagged for review.

Don’t stop at the signature. Ensure full provenance validation — know what was built, by whom, using which dependencies. Tools like in-toto, SLSA and SBOM generation solutions can help ensure that signatures are tied to a complete, verifiable chain of custody.

Adopt short-lived certificates and revocation mechanisms to reduce the blast radius. If a key is compromised or misused, organizations must be able to respond immediately by revoking trust and rotating credentials.

Crucially, invest in developer enablement. Developers are not cryptographers — and they shouldn’t have to be. Provide simple tooling, templates and education that make secure signing easy and error-resistant.

Finally, implement monitoring and anomaly detection for signing activities. Unusual signing behavior — like signing from an unexpected IP, service, or pipeline — should be treated as a potential breach and escalated accordingly.

These actions form a framework that moves code signing from a check-the-box task to a pillar of software trustworthiness.

The Checkbox Trap: Why Signatures Alone Aren’t Enough

A worrying trend is the “checkbox” mentality that surrounds code signing. Yes, your software is signed. But is it secure? Compliance might require a signature, but true assurance comes from layered validation, runtime introspection and knowing exactly what’s running in production.

As organizations strive to harden their software pipelines, it’s tempting to overvalue cryptographic proof. But trust is not binary. It’s dynamic. It must be earned and reaffirmed at every stage of the development and deployment lifecycle.

Conclusion: Trust, But Verify – and Then Monitor

Code signing, like many security tools, is powerful in theory and dangerous in isolation. It offers trust, but only to the extent that the surrounding processes are trustworthy. In the fast-moving world of DevOps, where builds, packages and deployments happen at breakneck speed, the biggest threat isn’t unsigned code – it’s unquestioned trust.

Security leaders must treat code signing as a control point, not a finish line. Don’t just ask, “Is it signed?” Ask, “Is it signed, tracked, validated and safe to run now and tomorrow?”

Trust begins at the signature. But in modern security, it never ends there.

June 9, 2025
DevOps: More Than a Buzzword—A Mindset of Continuous Evolution
In recent years, the term DevOps has become one of the most talked-about buzzwords in the technology world. You’ll hear it in boardroom discussions, IT conferences, job postings, and even startup meetups. Companies want to “go DevOps,” developers want to work in DevOps environments, and recruiters are constantly looking for DevOps Engineers. But despite all this hype, DevOps is often misunderstood. Many think it’s a tool or a new kind of job title. In reality, DevOps is not a technology—it’s a mindset.

This article explains what DevOps really means, why it’s important, and how it embodies a cycle of continuous practices—like continuous integration, continuous deployment, continuous testing, continuous monitoring, continuous security, continuous improvement, and continuous feedback. We’ll explore these concepts in simple language and explain how they align with business strategy and team collaboration.

What Is DevOps, Really?

DevOps stands for Development and Operations. It brings together software developers (who write the code) and operations teams (who deploy and manage the code in production). Traditionally, these two teams worked separately. Developers would build software and hand it over to operations to release. This handoff model caused delays, confusion, and sometimes even system failures.

DevOps aims to break down these silos. It promotes collaboration, shared responsibility, and faster delivery of high-quality software. DevOps is not a product you can buy or a process you can install. It’s a cultural shift—a new way of thinking about how teams work together to deliver value to customers.

Why DevOps Is a Mindset, Not Just a Tool

Many companies start their DevOps journey by adopting tools like Jenkins, Docker, Kubernetes or Terraform. While these tools help automate tasks, they don’t make an organization “DevOps-ready” by themselves. A DevOps culture is built on principles such as:
- Shared goals between development, operations, and business teams
- End-to-end accountability for software quality and performance
- Fast, safe, and frequent delivery of new features
- Embracing failure as a learning opportunity
- Continuous improvement and feedback
These principles require changes in how people work, how they communicate, and how they measure success. In other words, DevOps is a people-first approach, supported by tools—not the other way around.

Strategic Alignment: Connecting DevOps to Business Goals

One of the biggest benefits of DevOps is its ability to align IT efforts with business goals. When development and operations teams work closely with product managers and business leaders, they can prioritize features that deliver real value to customers.

For example, instead of spending months developing features that may never be used, a DevOps team can release small updates frequently, gather user feedback, and adjust the roadmap. This approach supports agile decision-making, reduces risk, and increases customer satisfaction.

DevOps also emphasizes metrics that matter to the business, such as:
- Deployment frequency
- Lead time for changes
- Mean time to recovery (MTTR)
- Customer feedback and satisfaction
These metrics help teams measure their performance and make data-driven decisions.

The Pillars of DevOps: A Culture of Continuity

DevOps is powered by a series of continuous practices. Let’s walk through each one and understand how they fit together.

1. Continuous Integration (CI)

Continuous Integration is the practice of automatically merging code changes into a shared repository several times a day. Every time a developer writes new code, it is tested and integrated with the existing codebase. This helps catch bugs early and ensures the software always stays in a working state.

Key benefits:
- Faster development cycles
- Reduced integration issues
- Early bug detection
CI tools: Jenkins, GitLab CI, CircleCI, Travis CI

2. Continuous Deployment (CD)

Once the code passes all the tests, it is automatically deployed to production or staging environments. This is known as Continuous Deployment. It removes manual intervention and allows teams to release features to users quickly and reliably.

Key benefits:
- Shorter release cycles
- Faster feedback from users
- Reduced manual errors
CD tools: Spinnaker, Argo CD, AWS CodePipeline

3. Continuous Testing

Continuous Testing ensures that the software is tested at every stage of the development lifecycle. This includes unit tests, integration tests, performance tests, and even security tests. Automated testing tools help identify defects early and prevent bugs from reaching the end user.

Key benefits:
- Improved quality
- Faster bug detection
- Increased confidence in releases
Testing tools: Selenium, JUnit, TestNG, Postman, SonarQube

4. Continuous Monitoring

After the software is released, it’s important to monitor its performance, availability and user behavior in real time. Continuous Monitoring helps detect issues early, prevent downtime, and understand how users interact with the application.

Monitoring also provides telemetry data, which can be used to improve future versions of the product.

Key benefits:
- Better uptime
- Real-time alerts
- Insights into user experience
Monitoring tools: Prometheus, Grafana, Datadog, New Relic, ELK Stack

5. Continuous Security (DevSecOps)

In the past, security was often added at the end of the development process. In DevOps, security is integrated from the beginning. This practice is called DevSecOps—short for Development, Security, and Operations.

Security checks are built into the CI/CD pipeline, and developers are trained to write secure code. Automated tools scan for vulnerabilities in real time.

Key benefits:
- Early detection of security flaws
- Lower risk of breaches
- Compliance with security standards
Security tools: Snyk, Aqua, Clair, Fortify

6. Continuous Feedback

Continuous Feedback means collecting real-time input from customers, end-users, and stakeholders. This feedback is then used to improve the product in the next cycle. It could come in the form of bug reports, customer reviews, surveys, or usage analytics.

Feedback is also encouraged within teams. Retrospectives, peer reviews, and performance metrics help teams learn and grow continuously.

Key benefits:
- Better user experience
- Product features that match real needs
- Faster response to change
Feedback tools: Jira, Slack, UserVoice, Microsoft Teams

7. Continuous Improvement

DevOps teams strive to improve with every sprint, release, and incident. This involves reviewing past performance, identifying bottlenecks, and experimenting with new ideas.

Key aspects include:
- Regular retrospectives
- Automation of manual tasks
- Process optimization
- Team learning and training
Continuous improvement is what turns a good DevOps team into a great one.

Benefits of a DevOps Mindset

Organizations that adopt a true DevOps mindset report several business and technical benefits:
1. Faster Time to Market
  Teams can deliver features, updates, and fixes faster and more frequently.
2. Better Collaboration
  DevOps breaks down silos, encouraging communication and shared responsibility.
3. Higher Quality and Reliability
  Frequent testing and monitoring improve the quality of software.
4. Stronger Security
  Security is integrated into every step, reducing risks and vulnerabilities.
5. Improved Customer Satisfaction
  Faster updates and quicker fixes enhance the customer experience.
6. Happier Teams
  Empowered teams that can deploy safely and frequently feel more motivated.
Challenges in Adopting DevOps

Adopting DevOps isn’t always easy. Some of the common challenges include:
- Cultural resistance: Changing mindsets takes time.
- Legacy systems: Old infrastructure may not support automation.
- Tool overload: Choosing and integrating the right tools can be complex.
- Lack of skills: Teams may need training in automation, cloud, and testing.
- Fragmented processes: Without a unified strategy, DevOps can become chaotic.
The key is to start small, show quick wins, and scale gradually.

DevOps Success Stories

Many companies have transformed their development culture through DevOps:
- Amazon deploys code thousands of times a day using DevOps automation.
- Netflix built its world-class streaming platform on DevOps principles.
- Etsy recovered from deployment issues by investing in a DevOps culture.
- Toyota (where I’ve had the honor to lead) leverages DevOps to enhance reliability, performance, and cost-efficiency in enterprise data platforms.
Final Thoughts: DevOps Is a Journey

DevOps is not a one-time project—it’s a journey of continuous transformation. It’s about creating a culture where development, operations, business, and security teams work together with shared goals, automated processes, and customer-centric thinking.

Yes, the tools matter. But more important is the mindset. When teams truly embrace DevOps, they move from delivering code to delivering value—faster, safer, and with greater impact.

So next time someone calls DevOps a “buzzword,” remember this: it’s not a trend, it’s a transformative philosophy—one that’s changing how the world builds and delivers technology.
May 29, 2025
Futurum Group Survey Surfaces DevSecOps Progress on Multiple Fronts

A survey of 110 security leaders finds all are investing in software supply chain security, with application security posture management (ASPM) and DevSecOps automation and orchestration topping the priority list, followed closely by security composition analysis (SCA) tools, application programming interface (API) security and dynamic application security testing (DAST) tools.

In addition, 30% of respondents expect to be piloting a software bill of materials (SBOM) initiative in the next 24 months, the survey finds.

However, the source of the funding for these initiatives is becoming more of a shared responsibility, with only 21% of respondents reporting that security budgets are the sole source. In fact, half of the respondents (50%) noted application development teams now own responsibility for application security.

Overall, only 25% of respondents said there is limited collaboration with application development teams, resulting in occasional friction, compared to 59% that said there is good collaboration with room for improvement. Only 16% said there is a tight partnership based on shared goals.

Fernando Montenegro, vice president and practice lead for cybersecurity, said it’s clear there is now more collaboration between application development and cybersecurity teams, with more security tools being incorporated into DevOps workflows. However, improving software supply chain security it’s also still very much a work in progress, he added.

The degree to which application developers might share the same level of optimism about the state of DevSecOps is less clear. Historically, many developers have resented requests to search for vulnerabilities in code that either never made it into an application running in a production environment or are only found in an application that isn’t accessible externally.

Additionally, no one is quite certain to what degree artificial intelligence (AI) is improving the quality of the code being generated versus making it worse. On the one hand, far too many application developers lack cybersecurity expertise, so much of the code they have generated has been flawed. However, general-purpose AI models have been trained using examples of flawed code randomly sourced from across the internet. Not surprisingly, large language models (LLMs) are generating code with known vulnerabilities.

Hopefully, the next generation of LLMs will be trained using examples of code that have been vetted for security flaws, which, when coupled with more advanced tools that are leveraging AI to discover vulnerabilities as code is being written, should eventually improve the overall state of application security.

Of course, it’s also safe to assume cybercriminal syndicates and various nation states are now also using AI to identify vulnerabilities in code, but also generate the code needed to exploit those vulnerabilities. As a result, the number of cybersecurity incidents involving legacy code is likely to dramatically increase in the months ahead.

DevOps teams at the very least should by now be reviewing what changes to existing DevOps workflows need to be made to achieve that goal. After all, the easiest vulnerability to fix is the one that was never created. The challenge, of course, is determining where the funding needed to acquire the tools and platforms that make it possible to build and deploy more secure applications is actually going to come from.

May 27, 2025
Continuous Compliance for Cloud-Native CI/CD Pipelines
In today’s cloud-native world, the race isn’t just about how fast you ship software — it is about how confidently you do it. For teams in highly regulated industries, speed without control is a liability. Compliance isn’t optional, but traditional approaches — manual reviews, static audits and post-deployment checks — are fundamentally at odds with modern DevOps workflows.

Enter continuous compliance: A shift-left, automation-first approach that integrates security and regulatory controls directly into continuous integration and continuous deployment (CI/CD) pipelines. Rather than bolting on compliance after the fact, teams can now build it into every pull request, infrastructure change and deployment cycle. The result? Shorter audit cycles, reduced risk exposure and uninterrupted delivery velocity.

This article explores the technical foundations and real-world practices for implementing continuous compliance in Kubernetes-based environments using tools such as open policy agent (OPA), Terraform, GitOps and cloud-native security scanners. Whether you are navigating Payment Card Industry Data Security Standard (PCI-DSS), Sarbanes-Oxley Act (SOX) or internal audit requirements, we will show you how to transform compliance from a bottleneck into a built-in feature.
1. Why Traditional Compliance Models Fail in DevOps
Most compliance frameworks were born in the age of waterfall development. Static change windows, monthly review boards and paper trails don’t fit in a world of ephemeral infrastructure and daily releases. DevOps teams that try to retrofit old-school compliance into modern workflows face constant friction — either slowing down innovation or accumulating risk.
1. Principles of Continuous Compliance
Continuous compliance is built on three key principles:
- Policy-as-Code: Compliance policies are written as machine-readable code that can be versioned, tested and deployed like application code.
- Automated Controls: Every commit or change triggers automated validations — from infrastructure as code (IaC) scanning to dependency checks to role-based access control (RBAC) evaluations.
- Audit-Ready Pipelines: Systems continuously collect evidence, producing real-time audit trails without human intervention.
1. Tooling the Pipeline for Compliance
To embed compliance into the delivery life cycle, you need a layered toolchain:
- IaC Scanners (e.g., Checkov, tfsec): Evaluate Terraform or CloudFormation for misconfigurations
- Policy Engines (e.g., OPA, Conftest): Enforce policies across CI pipelines, Kubernetes manifests and GitOps workflows
- Secrets and Dependency Scanners (e.g., Trivy, Snyk): Detect exposed secrets and vulnerabilities before runtime
- GitOps Workflows (e.g., Argo CD, Flux): Provide declarative state and automated drift detection for infrastructure changes.
1. Embedding Controls Across Stages
Let’s look at how continuous compliance fits into a typical CI/CD workflow:
- Pre-Commit: Developers run local checks using pre-commit hooks with Conftest or OPA to validate Kubernetes manifests and IaC
- Build: CI jobs scan for secrets, licenses and known vulnerabilities
- Deploy: GitOps agents enforce signed manifests, validate image provenance and run policy checks against cluster configurations
- Post-Deploy: Runtime observability tools log security events and auto-generate compliance reports.
1. Real-World Benefits
Companies that adopt continuous compliance frameworks report:
- 40–70% reduction in manual audit prep time
- 90% faster remediation for misconfigured resources
- Improved collaboration between Dev, Sec and Ops due to shared visibility and feedback loops.
1. Getting Started
- Start small with one compliance use case (e.g., S3 bucket encryption enforcement)
- Define policy-as-code in a repo and enforce it via CI checks
- Expand to runtime controls, GitOps enforcement and cross-account validation
- Involve auditors early — they will appreciate the transparency.
Conclusion

In the high-stakes world of regulated industries, continuous compliance is the missing bridge between DevOps speed and audit-grade accountability. It shifts compliance from an afterthought to an always-on, invisible guardrail — empowering teams to move fast without breaking the rules. For organizations modernizing their infrastructure and delivery pipelines, the future of compliance is not just continuous. It is code-driven, automated and built into every release.
May 22, 2025