devopsy.kinsta.cloud

Tag: devops security

GitHub Adds 37 New Secret Detectors in March, Extends Scanning to AI Coding Agents

GitHub shipped four secret scanning updates in March that collectively represent the most significant expansion of the platform’s credential detection capabilities in months. The numbers: 37 new secret detectors across 22 providers; 39 token types now push-protected by default; new validity checks for AI and developer infrastructure tokens; and — most notably — secret scanning that now works inside AI coding agents through the GitHub MCP Server.

For DevOps teams managing repositories where AI agents are increasingly generating code and opening pull requests, this last addition changes the security equation.

What Shipped in March

March 10: The big batch. 28 new secret detectors from 15 providers, including Vercel (six token types alone), Snowflake, Supabase, Lark, and Shopify. Push protection expanded to 39 detectors enabled by default — meaning commits containing matching secrets are blocked before they reach the repository. Validity checks added for Airtable, DeepSeek, npm, Pinecone, and Sentry tokens, automatically verifying whether detected secrets are still active so teams can prioritize remediation.

March 17: Secret scanning in AI coding agents. The GitHub MCP Server can now scan code changes for exposed secrets before commits or pull requests are made. In MCP-enabled environments, AI coding agents invoke the secret-scanning engine in response to prompts and instructions. Results include structured data with locations and details for any secrets found. This is in public preview for repositories with GitHub Secret Protection enabled.

March 23: Push protection exemptions at the repo level. Organizations can now designate specific roles, teams, and apps as exempt from push protection enforcement directly from repository settings. Previously, exemptions could only be managed at the organization and enterprise level. Exemption status is evaluated at the time of each push.

March 31: Nine more detectors. New secret types from seven providers, including LangChain, Salesforce, and Figma. Secrets from Figma, Google, OpenVSX, and PostHog are now push-protected by default. Validity checks added for npm access tokens.

Why the AI Agent Integration Matters Most

The March 17 MCP Server integration is the update that changes the operational model. When AI coding agents generate code — whether through GitHub Copilot, Claude Code, or any MCP-compatible tool — that code can now be scanned for secrets before it’s committed. The agent doesn’t need to know what a secret looks like. It sends the code to GitHub’s scanning engine and receives structured results.

This addresses a specific risk that’s growing as the volume of AI-generated code increases. Anthropic reported that code output per engineer grew 200% last year. GitHub Copilot’s coding agent now handles tasks autonomously through Jira and GitHub Issues. Cursor’s cloud agents run in isolated VMs, producing merge-ready PRs. The more code agents generate, the more opportunities for secrets to leak — whether from training data patterns, hallucinated credentials, or copy-paste from context that includes real tokens.

Having secret scanning available inside the agent’s workflow — not just as a post-commit gate — means credentials can be caught before they enter the repository at all. That’s earlier in the pipeline than push protection, which catches secrets at commit time, and earlier than alert-based scanning, which catches them after the fact.

“GitHub embedding secret scanning into its MCP Server positions credential detection where AI-generated code originates, inside the agent workflow. As coding agents produce pull requests autonomously, security enforcement that operates at commit time or post-commit faces a growing gap between code velocity and detection speed,” according to Mitch Ashley, VP and practice lead for software lifecycle engineering at The Futurum Group.

“Organizations deploying AI coding agents at scale need layered detection that starts inside the agent’s execution context. Teams applying the same credential hygiene assumptions to agent-generated code as human-written code will underestimate the exposure.”

The Provider Coverage Story

The specific providers added in March tell their own story about where secrets are leaking. Vercel got six new token types in a single update. Snowflake, Supabase, and Pinecone — core infrastructure for AI applications — all received new detectors. LangChain tokens are now detected, reflecting how quickly the AI agent framework ecosystem has become part of production infrastructure. DeepSeek tokens got validity checks, acknowledging the model provider’s growing developer footprint.

The push protection defaults are equally telling. When GitHub enables push protection by default for a token type, it means the pattern is reliable enough to block commits without generating excessive false positives. The expansion to 39 token types — including Airtable, Databricks, Heroku, PostHog, and Shopify — reflects confidence in the detection accuracy and a bet that developers would rather be blocked at commit time than deal with a leaked credential after the fact.

For free public repositories, push protection defaults apply automatically. That’s a significant security baseline for open-source projects where contributors may inadvertently commit credentials.

Validity Checks and Remediation Priority

The expanded validity checks for npm, Airtable, DeepSeek, Pinecone, and Sentry tokens address a practical problem in secret scanning: alert fatigue. Not every detected secret is an active credential. Some have been rotated. Some have expired. Some were test values that never worked.

Validity checks automatically verify whether a detected secret is still active. This lets security teams prioritize remediation — an active DeepSeek API key in a public repository is an immediate problem, while an expired Sentry token from a test environment can wait. GitHub previously improved validity checks for AWS Access Key IDs, where most alerts labeled “unknown” switched to “valid” or “invalid” after the update. That same pattern is now extending to more provider tokens.

What This Means for DevOps

March’s updates reflect a security infrastructure that’s adapting to how code is actually being produced in 2026. AI agents generate code at scale. That code flows through automated pipelines. Secrets can leak at any point — from the agent’s context, from patterns in training data, from copy-paste in prompts, from environment variables that get hardcoded by mistake.

GitHub’s response is to push detection earlier and make it available in more contexts: Inside AI coding agents via MCP, at commit time via push protection, and post-commit via alert scanning with validity checks. Each layer catches what the previous one missed.

The push protection exemptions at the repository level are the governance complement. Not every push needs to be blocked — CI/CD service accounts, security testing tools, and specific team roles may need exemptions. Managing those exemptions at the repo level rather than only at the org level gives teams more granular control without requiring administrator intervention for every exception.

For teams running AI coding agents in production, the recommended sequence is clear: Enable the GitHub MCP Server with secret scanning, enable push protection with appropriate exemptions, and use validity checks to prioritize remediation of active credentials. That gives you three layers of detection before a secret reaches production.

April 1, 2026
AWS CodeBuild Webhook Misconfiguration Exposed Admin Access Risk

AWS disclosed a security issue affecting four of its managed GitHub repositories that could have allowed attackers to introduce malicious code. The problem wasn’t a flaw in AWS CodeBuild itself—it was a configuration mistake in how webhook filters were set up.

Security researchers at Wiz found that regular expressions used to filter trusted actor IDs in CodeBuild webhooks weren’t properly anchored. This meant someone could create a GitHub account with a predictable ID and gain administrative access to affected repositories.

The issue affected aws-sdk-js-v3, aws-lc, amazon-corretto-crypto-provider, and awslabs/open-data-registry. AWS fixed the core problem within 48 hours of disclosure and confirmed no malicious code was introduced during the research.

How the Attack Worked

CodeBuild webhook filters are designed to limit which GitHub accounts can trigger builds. Organizations typically use the ACTOR_ID filter to specify which user accounts have permission to run builds on their repositories.

The problem was in how these filters were configured. The regular expressions used to match actor IDs weren’t anchored properly, allowing them to match partial strings rather than exact values.

Here’s a simplified example. If a filter is set to match the pattern “12345” without anchors, it will match “12345” but also “123456789” or “99912345”. An attacker who understands this pattern can create a GitHub account with an ID that matches the filter—even though it’s not the intended account.

The researchers demonstrated this by creating an account that satisfied the filter requirements and using it to commit code to one of the affected repositories. They immediately notified AWS Security rather than exploiting the access.

The Fix and Response

AWS moved quickly after the disclosure. Within 48 hours, they corrected the regex patterns in all four affected repositories. But they didn’t stop there.

The response included rotating credentials, adding protections to build processes that handle GitHub tokens or other sensitive data in memory, and auditing every AWS-managed open-source GitHub repository to identify similar misconfigurations.

AWS also reviewed CloudTrail logs and build repository logs to confirm no one else had exploited this issue. The audit showed that the researchers were the only ones to discover and demonstrate the vulnerability.

No customer environments were affected. No AWS services or infrastructure were compromised. The issue was isolated to the configuration of these specific repositories.

Why This Matters

This incident highlights a common issue in CI/CD security: access controls that appear sound but fail under scrutiny. Regular expressions are powerful but easy to misconfigure, especially when dealing with security boundaries.

The ACTOR_ID filter in CodeBuild is intended as a security control. When it’s misconfigured, it becomes a false sense of security—worse than no control at all because teams assume they’re protected.

“This incident shows how CI/CD risk often comes from configuration, not product defects. An unanchored regex effectively bypassed an access control, even though the tooling behaved as designed. As automation deepens inside delivery pipelines, security controls must be expressed with exact precision,” according to Mitch Ashley, VP and practice lead, software lifecycle engineering, The Futurum Group.

“Build systems should be treated as privileged infrastructure. They connect source code, credentials, and deployment authority, so small misconfigurations can scale quickly. The takeaway is to test security boundaries in practice, not by inspection, and to design CI/CD platforms with guardrails that assume configuration mistakes will happen.

Best Practices for CodeBuild Webhooks

AWS updated its documentation to emphasize proper webhook configuration. The key lessons apply to any CI/CD system, not just CodeBuild.

First, anchor your regular expressions. Use ^ at the start and $ at the end to ensure exact matches. The pattern should match the complete string, not just contain it somewhere.

Second, use CodeBuild’s pull request build policies as an additional layer of defense. This feature requires explicit approval before running builds from pull requests, even if the actor ID matches your filter.

Third, audit your existing configurations. Review all webhook filters and access controls in your build systems. Test them with accounts that shouldn’t have access to verify they’re properly restricted.

Fourth, treat build environments as privileged systems. They often have access to credentials, source code, and deployment pipelines. A compromise here can cascade through your entire infrastructure.

The Bigger Picture

This issue underscores the value of security researchers who practice responsible disclosure. Wiz demonstrated the problem, proved it was exploitable, and immediately worked with AWS to fix it. That’s how security research should work.

The incident also demonstrates that AWS’s response process is working correctly. Fast remediation, comprehensive audit, log review to confirm no other exploitation, and public disclosure with actionable guidance.

For development teams using CodeBuild or similar CI/CD tools, the takeaway is clear: review your webhook configurations now. Check your regex patterns. Verify they’re properly anchored. Test them with unintended inputs.

Security boundaries in automated systems must be precise. Close enough isn’t good enough when those systems have administrative access to your code repositories.

January 29, 2026
How to Integrate Quantum-Safe Security into Your DevOps Workflow

The rapid pace at which quantum computing is evolving is unprecedented, which is both good and bad news. While quantum computers can help solve complex problems at unimaginable speeds, they can also pose a serious threat to cryptographic algorithms that govern most modern security solutions.

Did you know that only 5% of enterprises around the world have implemented quantum-safe encryption, even though over 69% of them recognize the risks associated with quantum attacks?

With that in mind, let us look at the specific threats that quantum computing poses for your DevOps workflows before understanding how to protect them better.

Understanding Quantum Threats in DevOps

Most DevOps workflows currently deploy encryption schemes such as ECC and RSA, which are not very effective against quantum computers. As a result, you risk your sensitive data or important credentials getting leaked, and even severe security breaches.

Since DevOps pipelines handle rapid software releases while managing sensitive information, a quantum-enabled threat could be devastating. They could even lead to intellectual property loss, widespread service disruptions, and more.

How to Make Your DevOps Workflows Quantum-Safe?

The best quantum security products usually include encryption algorithms that can safeguard your workflows against threats launched by quantum computers. Now you know how quantum threats can disrupt your DevOps workflows, but here are the primary steps to follow when you are looking to integrate quantum-safe protocols in your DevOps:

1. Assess Your DevOps Pipelines for Vulnerabilities

Most organizations that are currently facing quantum threats lack a structured plan to address them. With that in mind, the first thing you need to do when building a quantum-resilient DevOps workflow is to identify and locate the vulnerabilities in it.

Review and analyze your CI/CD pipelines and map out every resource that relies on public infrastructure. Use assessment tools like Snyk or native integrations within GitLab to highlight configurations and dependencies that rely too much on non-quantum-safe algorithms.

2. Upgrade Communication and Data Security Protocols

To ensure that your DevOps workflow holds up against quantum threats, you must secure the information at rest and in transit. Consider implementing quantum-resistant encryption for your backups, credentials, pipeline secrets, and even internal communications, so that even your most sensitive data transfers remain safe.

Some organizations are even experimenting with quantum key distribution solutions to safeguard the most critical communications, while others are taking a hybrid approach combining encryption with post-quantum algorithms. If you often exchange build outputs, orchestration signals, and credentials in your communication, you are going to need all the security you can get.

3. Seamlessly Transition from Legacy to Quantum-Safe Protocols

The transition from your legacy systems and protocols to post-quantum cryptography can seem more daunting than it actually is. However, the operational risks and evolving industry standards make the process even more complicated. Moreover, most organizations now publish clear policies and guidelines for deployment in enterprise environments.

For smoother integration of post-quantum security protocols, DevOps teams must opt for a phased and crypto-agile strategy that lets them leverage their legacy and quantum-safe algorithms. Doing so can also help DevOps maintain interoperability and reduce any operational disruption.

4. Implement Quantum-Safe Security Automations in CI/CD Pipelines

By the time you reach this step, you are all set to implement your quantum-safe security strategy and start transforming your DevOps workflows. As part of the process, you will implement and embed code signing, dependency validation, and quantum-resistant security checks directly into your CI/CD pipelines.

Many cloud-based DevOps services have been adding support for post-quantum cryptography tools consistently, with the help of platforms such as GitHub and Jenkins. Adding quantum circuit checks and probabilistic test coverage can be especially beneficial for scaling DevOps teams that are experimenting with hybrid workloads and quantum software.

Another proven way to seamlessly integrate quantum-safe security automations in CI/CD pipelines is the containerization of security tools, which can help make your pipeline defenses more flexible and reproducible.

5. Monitor and Improve Security Measures Continuously

Quantum security is not a one-time undertaking and is a recurring initiative that requires consistent efforts and time from your end. As the standards for cyberattacks and cyberdefense evolve, monitoring and improving our quantum security protocols should be an important part of your security strategy.

You can also enhance your dashboards with quantum-specific metrics, such as cryptographic events and anomalies in encrypted traffic. Conduct training programs and industry workshops centered around the most recent quantum risks, requiring regular attendance.

To ensure that your security strategy is always up-to-date, audit your systems frequently, update protocols, and regularly upgrade training quality.

Concluding Remarks

Quantum computing is an operational reality today, affecting many scaling organizations around the world, and yet most of them are pretty underprepared. Most companies dealing with DevOps must implement quantum-safe protocols as soon as possible to adapt to the evolving security climate. With the help of ongoing learning and agile upgrades, you can take a critical step in future-proofing your security strategy and be a pivotal part of the quantum revolution.

October 30, 2025
Patch Management is Essential for Securing DevOps

Zero-day exploits don’t wait for anyone and are one of the main reasons why the cybersecurity market will be worth a whopping $256 billion worldwide. In the current threat landscape, attackers weaponize vulnerabilities within hours of disclosure, and that puts DevOps teams in a precarious position.

The ability to patch quickly and confidently can mean the difference between a minor blip and a full-scale breach. Yet patching often feels like firefighting — chaotic, reactive and disruptive. It doesn’t have to be this way. With the right pipelines and automation, patch management can become an ordinary, predictable part of the DevOps process rather than a heroic scramble.

Why Patch Management Belongs Inside DevOps

Patch management is not just an IT function anymore. It’s a critical piece of the software delivery lifecycle that intersects with build pipelines, runtime security, and continuous monitoring.

Vulnerabilities don’t discriminate between development and production; they surface wherever code runs. For DevOps teams, integrating patch management into the CI/CD process ensures vulnerabilities are discovered, patched and redeployed with minimal disruption.

Automated vulnerability discovery through CVE scanning is the cornerstone. Scanning images and packages during builds prevents unpatched dependencies from ever making it downstream.

When paired with Software Bill of Materials (SBOM)-driven dependency discovery, teams gain visibility into all components — even transitive ones hiding beneath direct dependencies. This visibility shortens the gap between identifying a vulnerability and knowing precisely where it exists in your stack.

Beyond discovery, DevOps pipelines allow controlled rollouts of patches. Canary releases, automated rollback policies and runtime feature flags make patching a continuous, non-disruptive process.

Automating Vulnerability Discovery

The speed at which vulnerabilities are identified and weaponized leaves no room for manual processes. Automation ensures DevOps teams detect issues before they cascade into production. CVE scanners integrated into CI/CD pipelines provide the first line of defense.

They evaluate images, containers, and packages for known vulnerabilities the moment they are built, catching risks before deployment.

SBOM integration adds another layer of intelligence. A detailed SBOM doesn’t just list dependencies; it connects components to specific vulnerabilities as databases like NVD update.

With this visibility, teams can map CVEs directly to affected services and prioritize patches based on severity and exposure. Automated dependency discovery closes gaps where teams may otherwise miss indirect or nested libraries that could still serve as attack vectors.

The process doesn’t end at build time. Continuous monitoring of registries and runtime environments ensures that newly disclosed CVEs trigger alerts even for already-deployed workloads.

Linking SBOM data with vulnerability feeds creates a dynamic system that evolves alongside the threat landscape. Instead of racing against attackers, DevOps teams can stay a step ahead by systematically automating discovery across the lifecycle.

CI Gating and Patched Artifacts

Discovering a vulnerability is only valuable if it’s followed by decisive action. This is where CI gating comes into play. By enforcing rules that block unpatched artifacts from progressing through the pipeline, DevOps teams make security non-negotiable. If a CVE is detected in an image or package, the build fails until a patched version is introduced.

Gating shifts patching from optional to required without disrupting workflow. Developers receive clear feedback during the build, allowing them to remediate vulnerabilities immediately rather than after release. This approach hardens the pipeline itself as a control point, ensuring that only secure artifacts advance to staging and production.

The automation doesn’t end at blocking. Once patches are applied, pipelines can automatically retest builds, revalidate dependencies, and redeploy with minimal manual oversight.

This creates a repeatable rhythm where patching is baked into delivery cycles, reinforcing security without slowing velocity. Ultimately, CI gating transforms patch management into an embedded safeguard rather than a last-minute fire drill.

Controlled Rollouts and Runtime Mitigation

Even the most carefully applied patch can introduce unforeseen issues. That’s why controlled rollouts and runtime mitigations are essential. Canary deployments allow teams to test patched versions with a limited subset of users, reducing the blast radius of potential failures.

Observability metrics track application health, performance, and error rates, enabling teams to validate patch stability before broader release.

Feature flags serve as another mitigation tool. If a patch interacts unpredictably with production systems, toggling a feature flag can disable risky components instantly without requiring a rollback.

Don’t Forget the Rollbacks

Meanwhile, automated rollback policies act as a final safety net. If observability detects significant anomalies, the system reverts to the last known good state with minimal downtime.

Runtime mitigation ensures DevOps teams don’t have to choose between risk and disruption. They can confidently release patches knowing safeguards exist if things go sideways.

This resilience not only secures systems but also builds trust across the organization that patching won’t derail customer experience. In practice, controlled rollouts transform patch management into an iterative, low-risk process aligned with DevOps culture.

Making Patching Routine, Not Heroic

Patching shouldn’t be a crisis. It should be as routine as code commits and unit tests. Achieving this cultural shift requires both technical pipelines and mindset alignment across DevOps teams.

Automation ensures consistency, but observability and rollback strategies make patching safe. Most importantly, integrating patch management into CI/CD makes it habitual — something developers expect, rather than dread.

Organizations that succeed in normalizing patching often treat it as part of their performance metrics. They measure mean time to patch (MTTP), track compliance with vulnerability SLAs, and tie patch frequency to overall system health. Over time, these metrics reinforce the idea that security and velocity are not opposing forces, but partners in delivering reliable software.

The payoff is profound. When patching is routine, DevOps teams spend less time firefighting and more time innovating. Customers experience fewer disruptions, compliance standards are met more easily, and attackers find fewer gaps to exploit.

Turning patch management into a predictable, embedded part of DevOps pipelines is not just about protecting systems; it’s about sustaining agility and trust in an environment where threats never wait.

Conclusion

The era of reactive patching is over. Attackers are faster, vulnerabilities surface constantly, and the old firefighting model is no longer tenable. For DevOps teams, the path forward is embedding patch management into the very fabric of CI/CD pipelines.

Automated discovery, CI gating, controlled rollouts, and runtime mitigations shift patching from crisis management to continuous practice. The teams that succeed will be those who treat patching as routine, not heroic, securing both their velocity and their resilience. In the end, patch management is about defending the pace and confidence of modern software delivery.

October 27, 2025
Git Services Need Better Security. Here’s How End-to-End Encryption Could Help

Your code repositories contain valuable intellectual property. They hold your organization’s proprietary software, configuration files and the entire history of your development work. But how secure are they, really?

Researchers from the University of Sydney, the University of Electronic Science and Technology of China, and Google have published a paper addressing a growing concern in the DevOps community: Git services like GitHub lack strong end-to-end encryption.

Why This Matters

Most development teams rely on platforms like GitHub, GitLab, or Bitbucket to manage their projects and collaborate across teams. These services work well for version control and collaboration, but there’s a problem. System breaches have become common, and the data stored in repositories can be highly valuable to attackers.

Think about what’s in your repositories. Source code, API keys (even if they shouldn’t be there), infrastructure configurations, and the complete history of your project’s development. If someone gains unauthorized access to your Git service provider’s systems, they can access all of that.

Current solutions don’t effectively address this problem. Some open-source projects have attempted to add encryption to Git workflows, but they suffer from two major issues: weak security guarantees and poor performance. The overhead is so large that most teams won’t adopt them.

What the Research Proposes

The paper introduces a formal approach to end-to-end encrypted Git services. Rather than treating encryption as an afterthought, the researchers defined the security properties that such a system should have and built two constructions that meet those requirements.

The key innovation is platform compatibility. Their approach works with existing Git servers without requiring changes to the underlying infrastructure. You can test and deploy these solutions on current platforms like GitHub or GitLab. All basic Git operations continue to work as expected.

But the real improvement is efficiency. Instead of encrypting and decrypting entire files or repositories with each operation, the overhead is proportional to the actual changes made. If you edit three lines in a file, you only pay the encryption cost for those three lines, not the entire file.

How it Works in Practice

The researchers tested both constructions on several public GitHub repositories. The results showed two important things.

First, platform compatibility works. The solutions integrate with existing Git infrastructure without breaking standard workflows. Developers can continue using the tools and processes they’re familiar with.

Second, the efficiency improvements are significant. Compared to previous attempts at securing Git repositories, these constructions dramatically reduce the overhead while providing much stronger security guarantees.

What This Means for DevOps Teams

End-to-end encryption for Git services would mean that even if your service provider’s systems are compromised, your code remains secure. The provider wouldn’t have the keys to decrypt your repositories.

This level of security has become standard for messaging apps and cloud storage. It makes sense to apply the same principles to Git services, especially given the value of what’s stored there.

For regulated industries, this could help meet compliance requirements. For any organization with valuable intellectual property, it adds an important layer of protection.

“Recent research demonstrates that end-to-end encryption for git is now technically possible and prototypes have been developed, but such encryption is not yet an industry standard nor widely implemented on Git-based platforms,” according to Mitch Ashley, VP and practice lead, software lifecycle engineering, The Futurum Group. “GitHub may lead the way on making security improvements as GitHub’s operations are moved onto Azure infrastructure and into Microsoft’s operations.”

The Path Forward

The research is still academic at this stage. These solutions need to be adopted by Git service providers or implemented as client-side tools that development teams can use.

The paper provides a formal framework for thinking about Git security and demonstrates that strong end-to-end encryption is possible without sacrificing usability or performance.

For DevOps practitioners, this research suggests that better security options may be coming. The challenge will be adoption. Security features that add friction tend to be avoided, but these constructions aim to minimize that friction.

If you’re concerned about the security of your repositories, this is worth following. The researchers have shown that we don’t have to choose between security and performance when it comes to Git services.

As system breaches continue to make headlines, end-to-end encryption for Git repositories could become a standard security practice. The technical foundation for making it practical now exists.

October 13, 2025
Worms in the Supply Chain: Shai-Hulud and the Next DevOps Reckoning
DevOps was supposed to make software delivery faster, safer and more reliable. For the most part, it has. But every so often, something nasty crawls out of the shadows and reminds us how fragile the system really is.

It wasn’t a zero-day in Kubernetes or a cloud misconfiguration that caught my eye. It was a worm. Not a metaphorical one, not a cute “bug.” A self-replicating, credential-stealing worm slithering through npm, GitHub, and CI/CD pipelines. Its name: Shai-Hulud, after the sandworms of Dune. And like those great worms of Arrakis, this one tunneled through the ground beneath our feet — our supply chain.

How Shai-Hulud Struck

Security researchers at Wiz, Zscaler and StepSecurity described how the worm infected 200+ npm packages and over 500 versions in just a few days. Some of those packages had millions of weekly downloads.

Once installed, the malware pulled in TruffleHog to scan for secrets in environment variables and config files. It stole GitHub tokens, dumped them into a public repo called Shai-Hulud, and then planted malicious GitHub Actions workflows for persistence. In some cases, it even migrated private repos to public forks — broadcasting secrets to the world.

Charlie Eriksen from Aikido summed it up: “At least 187 code packages … have been infected with a self-replicating worm that steals credentials from developers and publishes those secrets on GitHub.” That’s not a nuisance. That’s a supply chain wildfire.

Why This is a DevOps Problem

You could argue this is just another npm mess. “Don’t use random packages,” “lock dependencies,” “scan for secrets.” We’ve heard it all before. But if you’re in DevOps, you can’t shrug this one off.

Why? Because Shai-Hulud didn’t just target developers at their laptops. It went straight after the DevOps machinery: the pipelines, the tokens, the workflows. That’s our house. That’s our responsibility.

Think about what DevOps has become. CI/CD pipelines aren’t side projects — they’re the factories. Every commit goes in, every release comes out. If attackers compromise that factory, they don’t just own one app, they own everything that factory produces.

This worm was tailor-made for that reality.

Lessons for the DevOps Community

So what do we do about it? A few takeaways hit me square in the face:
1. Long-lived tokens are suicide notes. If your pipelines still rely on credentials that never expire, you’re inviting attackers to take up permanent residence. Shift to OIDC or short-lived tokens.
2. Pipelines must be locked down. Too many orgs let builds run with full internet access, install scripts from who-knows-where, and treat CI environments as disposable. They’re not disposable—they’re crown jewels. Lock them down.
3. Provenance is not optional. If you can’t prove where an artifact came from, you shouldn’t be shipping it. Signed builds, SBOMs, attestations — call it bureaucracy if you want, but it’s the only way to stop worms from tunneling in.
4. Golden paths need teeth. DevOps teams love paved roads, but paved roads without guardrails are just fast lanes to compromise. Harden your templates. Don’t make security an optional checkbox.
5. Continuous verification beats once-a-year audits. Secret scanning, anomaly detection, policy enforcement — these need to be continuous. A worm doesn’t wait for your quarterly review.
A Pattern We’ve Seen Before

If all this feels eerily familiar, it should. Every era of computing has had its worm moment. Networks had SQL Slammer. Email had ILOVEYOU. Mobile had Stagefright. And now, the DevOps era has Shai-Hulud.

The pattern is always the same: systems grow fast, guardrails lag, and attackers exploit the gap. Worms are the blunt instruments that expose just how thin our defenses really are.

Shimmy’s Take

For me, Shai-Hulud is more than a clever name in the npm registry. It’s a warning shot across the bow of DevOps. We’ve built incredible factories of automation, but too many of them are made of cardboard and duct tape.

The bad news? Worms thrive in that environment. The good news? We know what to do. Kill the zombie tokens. Lock down the build rooms. Demand provenance. Make golden paths truly golden.

DevOps was always supposed to be about culture and discipline, not just tooling. Shai-Hulud is reminding us of that in the harshest way possible. If we treat pipelines as disposable plumbing, they’ll fail us. If we treat them as infrastructure, they can withstand worms.

The spice — the code — must flow. But it’s up to us in DevOps to make sure it flows safely, not straight into the desert for the worms to feast on.
October 1, 2025
The DevSecOps Career Path: What No One Tells You About Getting Started

DevOps teams across organizations are suddenly finding themselves responsible for security with no roadmap. One day, teams are focused on deployment velocity and infrastructure automation, the next day, they’re expected to understand threat modeling, vulnerability management and compliance frameworks. This shift isn’t happening by choice — it’s happening because traditional security approaches can’t keep pace with modern development cycles.

The gap is real: DevOps professionals know they need security skills, but lack clear guidance on where to start. Most available resources either assume deep security expertise or offer surface-level tool tutorials that miss the bigger picture. Meanwhile, organizations desperately need people who can bridge the gap between rapid development practices and robust security postures.

This matters now because security can’t be an afterthought in modern development workflows. When applications deploy multiple times per day and infrastructure changes constantly, security must be built into every step of the process, not bolted on at the end.

What DevSecOps Really Means for Day-to-Day Operations

Most organizations think DevSecOps means simply adding security tools to existing pipelines. They assume it’s about running vulnerability scans in CI/CD workflows and checking compliance boxes. This surface-level understanding leads to implementations that slow down development without meaningfully improving security posture.

The reality is far more complex. DevSecOps requires shifting the team’s mindset from “speed first” to “secure speed.” It means learning to think like attackers while building like developers. Instead of treating security as a gate that slows down releases, successful DevSecOps professionals make security an accelerator that prevents costly incidents and rework.

DevSecOps professionals become bridges between security and development teams—translating business risk into technical action and technical findings into business impact. They don’t just run security tools; they understand when tools provide false confidence and when manual review is necessary.

The career impact is significant. DevSecOps roles command 15-25% higher salaries than traditional DevOps positions. More importantly, professionals with both security and DevOps expertise become indispensable because this dual skillset remains rare. Organizations depend on people who can speak both technical languages fluently.

But this transition isn’t automatic. It requires deliberate skill development and a fundamental shift in how professionals think about software delivery.

The Skills Gap No One Discusses

The technical competencies are just the beginning. DevSecOps professionals need to master security scanning integration—not just running SAST, DAST, and SCA tools, but understanding their limitations and interpreting results accurately. Infrastructure as Code security becomes critical when teams manage cloud resources through Terraform or CloudFormation templates that can inadvertently expose sensitive data or create overprivileged access.

Container and cloud security fundamentals matter because modern applications rarely run on traditional servers. Understanding how Kubernetes security contexts work, how container images can be compromised, and how cloud IAM policies interact with application permissions isn’t optional knowledge — it’s table stakes.

The technical skills are measurable and learnable. The soft skills determine whether professionals succeed or burn out in DevSecOps roles.

Risk communication separates successful DevSecOps professionals from tool operators. When a vulnerability scan returns 500 findings, someone needs to explain which five require immediate attention and why. This means translating technical vulnerabilities into business impact: “This SQL injection vulnerability in our payment processing service could expose customer credit card data, violating PCI compliance and potentially costing us $2 million in fines.”

Stakeholder management becomes critical when security requirements conflict with delivery timelines. Getting developers to prioritize security without slowing velocity requires understanding both perspectives. Successful DevSecOps professionals learn to present security as an enabler: “Implementing these input validation checks now prevents the three-day security incident response we had last quarter.”

Common misconceptions challenge transitioning professionals consistently. Many assume they can learn everything simultaneously, spreading effort across too many domains without developing deep competency in any. Others focus exclusively on tools without understanding underlying security principles, leading to false confidence when tools provide clean reports despite fundamental architectural vulnerabilities.

Perhaps most dangerously, some professionals never learn to communicate risk in business terms, remaining stuck in technical discussions that don’t resonate with decision-makers who control budgets and priorities.

The 6-Month DevSecOps Transition Framework

Months 1-2 focus on foundation building. Start by auditing current CI/CD pipeline security implementations. Most pipelines have basic security gaps that provide excellent learning opportunities. Look for secrets hardcoded in repositories, dependency vulnerabilities in third-party libraries, and deployment processes that lack proper access controls.

Master the OWASP Top 10 — not just memorizing the list, but understanding what systems actually need protection against. Each vulnerability category represents real attack patterns that affect production applications. SQL injection isn’t just a theoretical concern; it’s how attackers stole customer data from major retailers.

Select one security scanning tool and integrate it properly. “Properly” means understanding its detection capabilities, configuring it to minimize false positives, and establishing processes for addressing findings. Many teams install security tools but never develop workflows for acting on results.

Months 3-4 expand security perspective beyond pipeline tools. Infrastructure and container security become paramount as teams manage increasingly complex deployment environments. Learn how attackers exploit misconfigured cloud storage buckets, overprivileged IAM roles, and vulnerable container images.

Supply chain security basics matter because modern applications depend on hundreds of third-party components. Understanding how to assess dependency risks, monitor for newly disclosed vulnerabilities, and implement secure software supply chain practices prevents the kind of widespread incidents that affect thousands of organizations simultaneously.

Professionals focused on AWS environments should consider beginning AWS Security Specialty certification preparation during this phase. The certification process reinforces practical security concepts while building credibility with hiring managers.

Months 5-6 connect security activities to business impact. Learn to quantify security risks in terms that organizations understand. Instead of reporting “17 high-severity vulnerabilities,” explain “three vulnerabilities that could lead to data breaches affecting 50,000 customers, potentially costing $1.2 million in incident response and regulatory fines.”

Begin leading security conversations with development teams. This requires diplomatic skills—presenting security requirements as collaborative problem-solving rather than compliance mandates. Successful conversations focus on enabling secure development rather than restricting development practices.

Consider CISSP certification with five or more years of experience, or GSEC for those seeking hands-on security fundamentals. These certifications validate knowledge while building professional networks within the security community.

Immediate actions professionals can implement include conducting a pipeline security gap analysis. Review current deployment processes for obvious security weaknesses. Run vulnerability scans on key applications to understand baseline security posture. Schedule collaboration sessions with existing security team members to learn organizational risk tolerance and compliance requirements.

Avoiding Common Career Transition Traps

The biggest trap is becoming “security police” instead of enablers. Some DevSecOps professionals interpret their role as stopping insecure practices rather than enabling secure practices. This approach creates adversarial relationships with development teams and ultimately reduces security effectiveness.

Focusing solely on tools without understanding governance and compliance creates blind spots. Tools detect technical vulnerabilities but miss business context. Understanding why certain security controls exist—and when they can be adapted without compromising objectives—distinguishes strategic security professionals from tactical tool operators.

Many professionals fail to build relationships across both development and security teams. DevSecOps success requires trust from developers who see security professionals as collaborative partners and credibility with security teams who recognize technical competence. Building these relationships takes time and consistent demonstration of both technical skill and business judgment.

Perhaps most commonly, professionals treat DevSecOps as simply adding security tools to existing pipelines. This approach misses the cultural and process changes necessary for sustainable security improvement. Effective DevSecOps transforms how teams think about risk, not just which tools they run.

Next Steps for DevOps Professionals

Start with immediate actions that provide learning opportunities without disrupting existing workflows. Audit one critical application for security vulnerabilities. Review IAM permissions for cloud resources managed by Infrastructure as Code. Attend security team meetings to understand current organizational security challenges.

Measure transition progress through concrete security improvements rather than certifications earned or tools deployed. Track metrics like mean time to patch critical vulnerabilities, percentage of deployments that pass security scans, and developer satisfaction with security processes.

Build networks within the DevSecOps community through local meetups, online forums, and industry conferences. The field evolves rapidly, and staying current requires ongoing learning from practitioners facing similar challenges.

The DevSecOps career path isn’t just about adding security skills to existing DevOps expertise. It’s about fundamentally changing how organizations balance speed and security in software delivery. For DevOps professionals willing to make this transition thoughtfully, the opportunities are significant — and the impact on organizational security posture can be transformational.

September 22, 2025
Elevating DevOps Security: Why Integrating Threat Modeling Transforms Pentesting
Penetration testing (pentesting) has long been a cornerstone of security practices, particularly for meeting compliance requirements. However, a recent conversation with a client revealed a crucial gap in this approach. Critical vulnerabilities — particularly in their APIs and third-party software — remained unaddressed despite passing their pentest. While the pentest checked the compliance box, it did not account for the real world, evolving threats their system faced.

Although compliance-driven tests serve their purpose, they often leave organizations exposed to risks such as API abuse, supply chain vulnerabilities and insider threats. Many organizations treat pentesting as a routine task, missing out on a broader strategy to defend against the ever-changing threats.

Where Traditional Pentests Fall Short in a DevOps Environment

The compliance-driven pen tests tend to follow static checklists. This approach often overlooks the dynamic nature of modern infrastructures, especially in environments with rapid deployments, cloud services and third-party integrations. These tests may not adapt quickly enough to the new risks that emerge as the systems evolve.

For example, vulnerabilities in open-source components or dependencies in the software supply chain often go undetected in traditional pentests. This can create a false sense of security — your system may pass compliance, but still be vulnerable to real-world attacks.

Threat Modeling: A Shift Toward Risk-Based Testing

Integrating threat modeling into your security strategy offers a more tailored, risk-focused approach. Instead of asking ‘What is vulnerable’, threat modeling shifts the focus to ‘What could go wrong’ and ‘How could an attacker exploit this system’. This proactive method aligns with the fast-paced, iterative nature of DevOps, helping in identifying risks earlier in the development cycle.

In a recent case, we worked with a cloud-based company that had passed several pentests but was concerned about their API security. Through threat modeling, we uncovered a critical vulnerability in their session handling that previous tests had missed. The company mitigated a serious security risk by addressing this issue early before it could be exploited.

Optimizing Resources with Targeted Testing

One of the key benefits of integrating threat modeling with pentesting is the ability to focus resources where they matter the most. For DevOps teams managing fast-moving pipelines, threat modeling ensures that pentesting efforts are concentrated on high-risk areas rather than spread thin across the entire system.

For instance, consider a cloud infrastructure security test that used a threat modeling framework to target identity management. The test revealed vulnerabilities related to privilege escalation that a broad, compliance-focused pentest might have missed. This targeted approach allowed the team to resolve the issues quickly, reducing risk without overextending resources.

How to Integrate Threat Modeling Into Your DevOps Workflow

To make pentesting more effective and align security with your DevOps processes, consider integrating threat modeling into your workflow. Here are four actionable steps to get started:
1. Adopt a Threat Modeling Framework
  Use frameworks like STRIDE or PASTA to structure your threat modeling efforts. These frameworks help prioritize the attack vectors specific to your environment, allowing you to focus on the highest risks.
2. Automate the Threat Modeling Process
  In fast-paced DevOps environments, automation is essential. Automating threat modeling ensures that the models evolve as your system changes, continuously identifying the potential risks and updating security practices. This prevents critical vulnerabilities from being overlooked as development progresses.
3. Embed Threat Modeling in CI/CD Pipelines
  To align security with DevOps, threat modeling should be embedded into your CI/CD pipeline. This allows teams to catch vulnerabilities early before they reach production. Integrating threat modeling into build and deployment processes ensures that the security is proactive, not reactive.
4. Foster Cross-Team Collaboration
  Threat modeling should involve more than just security professionals. Developers, architects and operations teams must collaborate to ensure the threat model reflects the system’s architecture and business needs. This cross-functional approach creates a holistic view of potential risks and strengthens your defenses.
Case Study: Threat Modeling for Cloud Security

A healthcare provider applied the STRIDE methodology to their cloud infrastructure, focusing specifically on identity management and session handling. By using this threat modeling framework, they identified vulnerabilities related to privilege escalation that the previous pentests had missed. This allowed the team to prioritize their pentesting efforts on the critical areas, ensuring that these vulnerabilities were resolved before the attackers could exploit them.

Why Threat-Driven Testing is Essential for DevOps

The future of pentesting in DevOps lies in shifting from compliance-focused to threat-driven approaches. By aligning testing with real-world risks, organizations can move beyond a static checklist and address the actual threats they face. This approach offers a more holistic and adaptable security strategy.

The DevOps teams can combine threat modeling with red team exercises and adversary simulations to test their defenses against sophisticated attack scenarios. These simulations emulate real-world adversaries, allowing the organizations to see how they would fare against insider threats or advanced persistent threats (APTs). This level of testing, driven by identified risks, ensures that your security posture can evolve as your system evolves.

Conclusion: Moving Beyond Compliance for Stronger Security

Relying solely on compliance-driven pentesting is no longer enough to safeguard modern, fast-moving DevOps environments. To stay ahead of the evolving threats, organizations need to integrate threat modeling into their security strategies. This approach goes beyond checking boxes — it enables teams to identify the most critical risks and address them proactively.

By adopting structured threat modeling frameworks, automating the process and embedding it into CI/CD pipelines, the DevOps teams can ensure that security is an ongoing, integral part of their workflow. Collaboration across teams further ensures that the security model aligns with both the system architecture and operational goals.

As attackers continuously evolve their tactics, your testing strategies must evolve too. Do not stop at compliance — embrace threat-driven pentesting and build a security posture that is ready for the real-world threats your organization faces.
October 2, 2024
5 Security Threats DevOps Teams Should Know

DevOps security, also known as DevSecOps, is a philosophy in which security practices are integrated into the DevOps process. DevOps security involves creating a ‘security-as-code’ culture with ongoing, flexible collaboration between release engineers and security teams. The DevSecOps movement, much like DevOps itself, is focused on creating new solutions for complex software development processes within an agile framework.

DevOps security is about breaking down silos and promoting open collaboration across teams. It’s about making everyone accountable for security with the ultimate aim of improving the quality and speed of code releases. The adoption of a DevOps security model necessitates a cultural shift across the organization. It requires the integration of security into every aspect of the development and operations processes.

DevOps Security is not just about implementing tools and technologies; it’s about changing the way we look at security. Rather than being an afterthought, security should be a key part of the ongoing conversation from the start of the project to the end.

5 Security Threats DevOps Teams Must Know About

As a DevOps professional, it’s crucial to be aware of the potential threats that could compromise your systems, applications, and data. Let’s take a look at the top five security threats that DevOps teams must be aware of.

Phishing Attacks

Phishing attacks are a common security threat that can lead to data breaches. These attacks involve cybercriminals impersonating legitimate organizations to trick individuals into revealing sensitive information, such as passwords and credit card numbers.

Phishing attacks can be particularly damaging for DevOps teams. They can lead to unauthorized access to development systems and data, which can lead to devastating supply chain attacks. For example, an attacker could trick a team member into revealing their login credentials for a critical system, allowing the attacker to gain access and inject malware into a CI/CD pipeline.

Code Injection

Code injection is another common security threat that DevOps teams must be aware of. This involves the exploitation of an application by injecting malicious code. The attacker can then execute the malicious code to compromise the system or steal sensitive data.

For DevOps teams, code injection attacks can be particularly harmful. These attacks can lead to compromised systems and applications, resulting in data breaches and significant downtime.

Man-in-the-Middle Attacks

Man-in-the-middle attacks are a type of security threat where the attacker intercepts and potentially alters the communication between two parties without their knowledge. This can lead to a range of damaging outcomes, including data theft, session hijacking, and even identity theft.

For DevOps teams, man-in-the-middle attacks can be particularly problematic. These attacks can lead to compromised systems and data, and even the unauthorized alteration of code.

Container Vulnerabilities

Container vulnerabilities are a significant security threat for DevOps teams. Containers are a key technology in the DevOps world, allowing for the rapid and reliable deployment of applications. However, like any technology, they come with their own set of security risks.

These vulnerabilities can range from use of insecure images, to misconfigurations and software bugs, to more serious issues like kernel exploits. If an attacker is able to exploit a container vulnerability, they could potentially gain control over the entire system.

DDoS Attacks

Last but not least, distributed denial-of-service (DDoS) attacks are a significant security threat that DevOps teams must be aware of. These attacks involve overwhelming a production environment with traffic, causing it to become unavailable to users.

For DevOps teams, DDoS attacks can be particularly damaging. Not only can they lead to significant downtime, but they can also result in lost revenue and damage to the organization’s reputation.

How to Mitigate These DevOps Security Threats

While these security threats are concerning, there are effective strategies and techniques that can be used to mitigate them.

Implement Email Security Practices and Tools

To combat phishing attacks, it’s crucial to implement email security tools that can detect and block phishing attempts. These tools can help to filter out phishing emails, reducing the likelihood that team members will fall victim to these attacks.

In addition to implementing email security, it’s also important to provide security awareness training for team members. This training should cover the basics of cybersecurity, including how to recognize and respond to phishing attempts.

Use Input Validation and Sanitization in Applications

To protect against code injection attacks, it’s important to use input validation and sanitization in applications. Input validation involves checking that the data provided by a user meets certain criteria before it’s processed by the application.

Input sanitization, on the other hand, involves cleaning up the data to remove any potentially harmful elements. This can help to prevent malicious code from being executed within the application.

Employ HTTPS and SSL/TLS Encryption for Data in Transit

To guard against man-in-the-middle attacks, it’s important to employ HTTPS and SSL/TLS encryption for data in transit. This ensures that any data being sent between the user and the application is encrypted, making it much more difficult for an attacker to intercept and read the data.

Regularly Scan Containers for Vulnerabilities

To protect against container vulnerabilities, it’s crucial to regularly scan containers for vulnerabilities. This involves using tools that can analyze the containers and identify any potential security risks.

By regularly scanning containers, DevOps teams can identify and address vulnerabilities before they can be exploited by an attacker.

Implement Rate Limiting and Network Filtering

Finally, to mitigate the risk of DDoS attacks, it’s important to implement rate limiting and network filtering. Rate limiting involves restricting the number of requests that a user can make to the application within a certain period of time.

Network filtering, on the other hand, involves blocking traffic from certain IP addresses or ranges that are known to be associated with DDoS attacks. This can help to reduce the impact of a DDoS attack and protect the availability of the application.

In conclusion, DevOps security is a crucial aspect of the DevOps process. By being aware of potential security threats and taking steps to mitigate them, DevOps teams can significantly reduce the risk of a security breach and ensure the ongoing success of their projects.

January 25, 2024
A DevOps Guide to the Language of DevSecOps
Security is increasingly important for DevOps due to the growing complexity of applications and the accelerated pace of development. As organizations adopt DevOps practices, they face new challenges in securing applications and infrastructure:
- Increased complexity and automated processes: With automation at the core of DevOps, processes and applications are more intricate. This can introduce vulnerabilities if not carefully managed and secured, as they often involve multiple systems and components that need to be protected.
- Reliance on code repositories: DevOps teams depend heavily on code repositories for version control and collaboration. However, these repositories can be targets for attackers seeking to inject malicious code or steal sensitive information, making it crucial to secure access and maintain good security practices.
- Larger attack surface: The DevOps pipeline consists of numerous tools and components, including source code management, build systems, testing frameworks and deployment tools. Each of these elements presents potential attack surfaces and needs to be secured to protect the overall application.
- High-velocity development: The rapid pace of development in a DevOps environment can sometimes lead to security being overlooked or deprioritized. As new features are pushed out quickly, there may be less time for thorough security reviews.
- Tooling limitations: While many DevOps tools come with built-in security features, these may not be sufficient to protect against all threats. Relying solely on these features could create a false sense of security, leaving organizations exposed to potential attacks.
What is DevSecOps?

DevSecOps enables teams to shift security left and integrate it continuously across the entire SDLC rather than as an afterthought. It is a cultural shift even for DevOps teams, as it requires all members to adopt a security mindset that ensures software is not only released fast and at the highest possible quality but also includes all security measures and checks from the design phase.

It typically involves adopting secure coding practices and implementing application security testing tools that help design, test, verify, release, and update secure software in a secure manner. It requires ensuring that not only the software itself is secure, but also the development environment and the entire supply chain is secure. As a result, DevSecOps rely on a high level of automation tools to reduce manual work to a minimum.

DevOps Guide to Security Acronyms

All DevOps pros need to become familiar with key security concepts. Here are a few concepts that will help you communicate better with security teams in your organization and one day become a DevSecOps geek yourself.

1. SBOM—Software Bill of Materials

A software bill of materials (SBOM) comprises all components and software dependencies in the application’s build and delivery. It provides visibility into all the different components and licensing included in a piece of software to help discover potential vulnerabilities and licensing risks.

2. DAST – Dynamic Application Security Testing

DAST involves analyzing applications or services while they are running to identify security vulnerabilities. This technique typically simulates attacks to learn how a malicious actor might exploit the user or application interface. Teams use DAST tools to detect complex vulnerabilities caused by specific functionality that a static analysis tool cannot find when analyzing the source code.

3. SCA – Software Composition Analysis

SCA tools identify security vulnerabilities in third-party components and dependencies. Teams can integrate SCA to run across the entire development pipeline to build an open source dependency tree for the application and map these components against a database of known vulnerabilities. The tool generates reports on vulnerable open source components found in the application that require fixes or patches.

4. SAST – Static Application Security Testing

SAST tools analyze the source code of applications, services, and microservices, trying to identify potential vulnerabilities caused due to insecure coding practices. Teams can integrate SAST tools into their continuous pipeline, setting them up to automatically search the source code for coding patterns and insecure objects or functions that can result in security vulnerabilities. SAST is commonly used to identify vulnerabilities during the coding phase or when pushing code to a testing environment.

5. IAST—Interactive Application Security Testing

IAST involves analyzing the source code for vulnerabilities while the application is running. The main advantage of IAST is that this method reports vulnerabilities in real-time and does not add additional time to the CI/CD pipeline. It works from within the application, distinguishing it from both SAST and DAST techniques that work externally. IAST does not scan the entire codebase. Instead, it checks only the aspect exercised during the functional test.

6. RASP—Runtime Application Self-Protection

RASP is a defensive technique built into the tested application to detect and respond to attacks as they occur. It is typically implemented using third-party tools embedded within the application to monitor incoming requests and the application’s behavior, such as packages, plug-ins or libraries. These components inspect requests and the application’s behavior to block and protect against threats.

7. OWASP—Open Web Application Security Project

OWASP is a nonprofit devoted to helping improve software security by offering free resources and tools. This organization consists of a large community of volunteers who help propose, build and manage projects and educational materials that support the wider software development and security community.

8. XDR—Extended Detection and Response

XDR solutions collect and correlate deep activity data and detections across various security layers, including endpoints, emails, servers, networks, and cloud workloads, performing automated analysis to help detect threats faster. Teams can use this information to take quicker action during investigations. The main advantage of XDR solutions is that they help break down the security silos that allow stealthy threats to evade detection.

9. XSS—Cross-Site Scripting

XSS is a security vulnerability. It plagues so many web applications that it has yet to be removed from the OWASP Top 10 web vulnerabilities list since it was first included in the 2003 version. XSS vulnerabilities enable threat actors to execute malicious script code in one or multiple users’ browsers. Actors often use XSS to gather sensitive information, such as user session details and personal data.

10. SQLi—SQL Injection

SQLi is a code injection technique that enables threat actors to attack applications. It typically occurs when applications require user input, such as usernames, but receive a malicious SQL statement instead. To launch this attack, actors must locate vulnerable user inputs in the web application, create input content and send it. If the database executes the malicious SQL command, the attacker gains access to the database.

11. CSRF—Cross-Site Request Forgery

CSRF is a common web application attack that exploits the trust between a user and an application to conduct various malicious actions. Threat actors use CSRF to hijack an authenticated session between a user’s browser and an application. Once actors have access to the session, they can use it to execute functionality on that application.

12. SAML—Security Assertion Markup Language

SAML is a standard used to securely share information about identities, authentication, and authorization between various systems. It is typically implemented with the Extensible Markup Language (XML) standard for data sharing and often provides an open framework to implement a federated identity system like single sign-on (SSO).

Conclusion

In today’s chaotic cyber landscape, DevOps teams cannot solely prioritize the fast release of high-quality software. To ensure their software, infrastructure and development environment are protected, DevOps teams must integrate security into the entire SDLC. This endeavor requires adopting a security mindset and utilizing tools that help create an efficient and secure pipeline.

The acronyms discussed in this article include essential security aspects DevOps teams should get familiar with, such as the OWASP organization that provides important guidance on building secure software, tools that help shift security left and common web vulnerabilities. However, teams should branch beyond these practices and tools to create a comprehensive security policy that covers their unique needs and requirement.

Image Source
April 7, 2023