staging-devopsy.kinsta.cloud

Tag: microservices security

AI-Powered DevSecOps: Navigating Automation, Risk and Compliance in a Zero-Trust World
The rapid adoption of AI-powered automation in DevSecOps is like handing out power tools to highly capable interns; they have all the knowledge, but not necessarily the wisdom to use them effectively. Everything moves faster in some ways, but not always smoother. While we have reduced the sweat from toil, we have traded it for sweat from non-deterministic surprises. Threat detection, policy enforcement, compliance reporting — all streamlined, all automated, all shiny.

But let’s not fool ourselves. With every new lever of automation comes a hidden trap door. AI-driven security is great — until it isn’t. Until it starts making decisions in the dark, failing quietly, spectacularly and leaving you with a compliance nightmare that no audit committee wants to wake up to.

What happens when AI-generated security policies do not align with actual regulatory requirements? What if automated threat detection starts flagging the wrong behaviors while missing the real threats? Who is accountable when an AI-driven enforcement action locks critical teams out of production at the worst possible time?

How do we ensure AI-driven security does not turn into a black-box bureaucracy running on vibes and probability? In a zero-trust world where no one gets a free pass — not even the machines — how do security leaders keep their organizations from automating themselves into a false sense of safety?

This article will break down how artificial intelligence (AI) is reshaping DevSecOps, the security pitfalls that come with it and how to balance the raw efficiency of automation with the actual realities of risk mitigation. In highly regulated industries, compliance isn’t optional, and blindly trusting in automation is a whisker away from getting your infrastructure dismantled by an attacker, an auditor or both.

The Promise of AI in DevSecOps

Traditional security approaches often struggle to keep pace with rapid software development cycles and cloud-native complexity. AI-powered automation is revolutionizing DevSecOps by:
- Automating Threat Detection: AI-driven tools analyze vast telemetry data to detect anomalies and predict potential breaches.
- Enhancing Vulnerability Management: AI accelerates the discovery and prioritization of software vulnerabilities, integrating security into CI/CD pipelines.
- Continuous Compliance Monitoring: AI-powered automation ensures real-time policy enforcement for frameworks such as FedRAMP, NIST 800-53, ISO 27001 and DoD SRG IL5.
- Reducing False Positives: Machine learning (ML) models refine security alerts, reducing noise and allowing security teams to focus on real threats.
Andrew Clay Shafer, a foundational voice in the DevOps movement, shared his perspective on AI in governance, risk and compliance (GRC) automation:

”I am fascinated with GRC automation — AI-driven or not. I think large language models (LLMs) are mostly good for one thing: Generating. They can be quite bad at decision-making. Some of the thinking models are improving, but in many cases, other AI/ML approaches are far more appropriate than trying to throw LLMs at everything.”

AI and the Zero-Trust Model: Challenges & Risks

As organizations embrace zero-trust security, AI-driven automation introduces both opportunities and challenges:
1. AI-Driven Security: A Double-Edged Sword
While AI enhances security enforcement, over-reliance on automation can lead to blind spots, especially when dealing with zero-day vulnerabilities or adversarial AI attacks.
- Risk: As with any security system, AI-powered controls are fallible — they may misclassify threats or fail to detect novel attack techniques.
- Mitigation: Although it is a challenge, security teams’ due diligence to implement explainable AI (XAI) models that allow human analysts to understand and validate AI-driven security decisions goes a long way.
1. Compliance vs. Agility: The Balancing Act
AI-driven automation ensures compliance at scale, but regulatory frameworks like FISMA, FedRAMP and NIST RMF require a careful balance between automated security enforcement and human intervention.
- Risk: Automated compliance checks may miss context-specific security gaps, leading to non-compliance in highly regulated industries (e.g., finance, healthcare, government).
- Mitigation: Organizations should integrate AI-driven GRC tools with human validation to maintain accountability and regulatory alignment.
1. AI Security Models: The Risk of Bias and Exploitation
AI models trained on biased or incomplete datasets can introduce vulnerabilities into security automation. Attackers may also attempt adversarial ML attacks, manipulating AI-driven security systems.
- Risk: Poisoning attacks can corrupt AI training data, causing security models to misclassify malicious activities as benign, while model drift over time can degrade accuracy and introduce blind spots.
- Mitigation: AI-driven security solutions must incorporate continuous model validation, adversarial testing, robust data hygiene and model drift detection to prevent bias, manipulation and performance degradation.
The Power of DevOps for Rapid Development

DevOps has revolutionized software development, enabling rapid iteration, continuous integration and faster deployment cycles. By automating infrastructure provisioning, security testing and deployment workflows, DevOps teams can ship code faster without compromising security.

AI-powered DevOps, often referred to as AIOps, takes this further by leveraging ML for code generation, anomaly detection, predictive maintenance and automated remediation. However, while AI can dramatically improve efficiency, it is fallible — and its limitations in coding can introduce security vulnerabilities, compliance issues and misconfigured infrastructure if left unchecked.

Below are some common mistakes that AI makes in DevOps coding, with real-world examples and code snippets to highlight potential risks. These might seem like obvious ‘gotchas’ — things every DevOps engineer knows instinctively — but in the rush of rapid development and automation, even seasoned pros can overlook them.
1. AI Generating Hardcoded Secrets in Code
AI-driven coding assistants, like ChatGPT or Copilot, sometimes hardcode API keys, credentials and secrets directly into source code, creating serious security risks if not caught during code review.

🚨 Example: Hardcoded AWS Credentials in Python

An AI-generated DevOps script might unknowingly include credentials in plaintext:

⚠️ Why is it Dangerous?
- Hardcoded secrets violate the best security practices and can be leaked in repositories like GitHub.
- Attackers scrape public repos for credentials using automated tools.
- AI-generated scripts may overlook compliance policies requiring secrets management via environment variables or vaults.
✅ Better Practice: Use Environment Variables or AWS Secrets Manager
1. AI Misconfiguring Infrastructure as Code (IaC) With Open Permissions
When AI generates Terraform or AWS CloudFormation templates, it often grants excessive permissions for simplicity, leading to security misconfigurations.

🚨 Example: Terraform identity and access management (IAM) Role with Wildcard (*) Permissions

AI-generated Terraform might allow full administrative access, creating a zero-trust violation:

⚠️ Why is it Dangerous?
- Grants full control over all AWS resources (high privilege escalation risk).
- Violates least privilege security best practices.
- Would fail compliance checks (e.g., FedRAMP, NIST, ISO 27001).
✅ Better Practice: Restrict Permissions to Specific Actions and Resources
1. AI Overlooking Secure CI/CD Pipeline Configurations
AI-powered continuous integration/continuous delivery (CI/CD) automation tools can inadvertently introduce insecure configurations, such as running builds as root or failing to sanitize inputs in deployment scripts.

🚨 Example: AI-Generated GitHub Actions Workflow with Unrestricted Docker Build

⚠️ Why It’s Dangerous?
- No cache or dependency verification, risking insecure dependency injection.
- The container is built with default privileges (potential root execution).
- No code scanning or security linting step before deployment.
✅ Better Practice: Hardened CI/CD Pipeline with Security Checks

Key Takeaways: AI in DevOps Needs Human Oversight

AI can accelerate DevOps, but it does not inherently understand security context. Instead, AI generalizes from training data and patterns, which may include biased, outdated, or incomplete security assumptions. While AI-driven automation can improve efficiency, it also introduces risks when blindly applied to security-critical decisions. The best approach to AI-powered DevSecOps includes:
- AI-Augmented Security Reviews: Use AI-driven static analysis and dependency scanning but ensure human validation for security-critical code changes.
- Context-Aware Access Controls: AI may suggest least privilege IAM policies, but human oversight is required to prevent misaligned permissions from past patterns.
- Dynamic Threat Detection, Not Just Static Patterns: AI excels at detecting known patterns but struggles with novel attack techniques — use continuous monitoring with anomaly detection.
- Automated Security Testing with Real-Time Feedback Loops: Train AI models with real-world security incidents to improve detection accuracy over time, preventing model drift.
- Explainability & Trust in AI Security Decisions: AI’s black-box nature can introduce blind spots — use explainable AI (XAI) techniques to validate security recommendations before applying them in production.
AI is a powerful force multiplier in DevSecOps, but it requires structured feedback, human oversight and continuous validation to avoid reinforcing flawed security patterns. Organizations that blend AI speed with human expertise will gain efficiency without sacrificing security posture.

Best Practices: Implementing AI-Powered DevSecOps Securely

To harness AI’s full potential while minimizing security risks, organizations should follow these best practices:
1. Adopt a Human-in-the-Loop Approach
AI should augment, not replace, security teams. Implement human review processes for high-impact security decisions, such as automated threat containment and policy enforcement.
1. Leverage XAI for Transparency
Ensure AI-driven security tools provide explainable outputs that security analysts can validate. Avoid ‘black-box’ AI models with opaque decision-making.
1. Integrate AI-Driven GRC Solutions for Compliance Automation
Use AI-powered GRC platforms to automate regulatory audits and real-time compliance enforcement while ensuring human oversight in high-risk scenarios.
1. Train AI Models with Secure Data & Regular Adversarial Testing
Continuously test AI models for biases, vulnerabilities and adversarial threats to maintain trust and resilience in automated security systems.
1. Implement Continuous AI Security Monitoring
Monitor AI-driven security decisions in real-time, ensuring that security teams can intervene when necessary. AI security models should undergo regular retraining to adapt to evolving cyber threats.

Conclusion: The Future of AI in DevSecOps

AI isn’t magic, and is also not a security blanket. It is just another tool — one that can break things faster, at scale and with a CI/CD pipeline to failure if you are not paying attention. DevSecOps is not about automating trust; it is about eliminating blind spots. ‘Ship it and fix it later’ does not work when your AI just auto-owned production. If you are betting on AI to save you, you are already losing.

The real game is designing security that learns, adapts, and does not need a babysitter. Zero-trust is not a product, compliance is not security and ‘just use ML’ is not a strategy. AI won’t fix bad security hygiene — so, build like failure is inevitable, because it is. And if your AI starts committing to main, you might want to revoke its secure shell or secure socket shell (SSH) keys before it deploys Skynet.

Are you integrating AI-powered automation into your DevSecOps strategy? Share your insights in the comments below!
May 5, 2025
ARMO Aims to Simplify Microservices Security

ARMO this week emerged from stealth to launch a platform to secure cloud-native workloads and improve visibility. The ARMO Workload Fabric technology attaches code within the memory invoked by a microservice to enable cybersecurity policies to be applied via a cloud service.

Company CEO Shauli Rozen said the ARMO Workload Fabric is designed to enable IT organizations to implement a zero-trust architecture more easily within the context of a DevSecOps workflow.

Fresh from raising $4.5 million in seed funding, Rozen said ARMO’s approach eliminates the need to deploy and manage agent software, container sidecars or runtime application self-protection (RASP) software to enforce security policies across what inevitably will become thousands of microservices distributed across an enterprise IT environment.

That leaner approach then allows for a centralized management platform that can be deployed on a cloud or on-premises IT environment to apply policies that restrict which microservices can communicate with one another, Rozen said. The approach would ensure that only microservices developed using a continuous integration/continuous delivery (CI/CD) platform are allowed to communicate with other microservices, Rozen said.

Integration with multiple CI/CD platforms is already provided, added Rozen.

That approach allows policies to be applied to microservices regardless of how they are constructed, Rozen said. That capability is critical, because developers are building microservices using everything from Python and Java to containers, he said. Many of those microservices are also frequently replaced, Rozen said, which can make updating any associated agent software a significant DevOps challenge. Given all the existing dependencies between microservices, overall application environment security is only as strong as the proverbial weakest link. The ARMO Workload Fabric enables developers to add a small amount of code to implement security policies each time a microservice is rolled out into a production environment.

As part of an effort to make it simpler for IT organizations to apply those policies, ARMO provides a pre-built set of policies that organizations can immediately apply, in addition to creating their own polices over time, Rozen said. In many cases, IT teams simply don’t have the time or expertise required to build those policies, Rozen added.

Microservices are being built and deployed at such a breakneck pace that it’s nearly impossible for cybersecurity teams to keep up. The ARMO Workload Fabric provides cybersecurity teams a means to centrally manage security policies that would otherwise be implemented as code by developers. It provides a level of observability for how those cybersecurity policies are being implemented across microservices that typically have a lot of dependencies on one another, Rozen said.

Most organizations today recognize there is a clear need to shift responsibility for application security further left toward developers. The challenge is finding a practical way to achieve that goal, and in a way that doesn’t adversely impact the rate at which applications are being developed. The key to achieving that goal is finding a way to apply microservice security polices that causes the least amount of friction possible to existing DevOps workflows.

January 29, 2021
4 Things Developers Should Know About Security in the Age of DevSecOps

If you’re a developer, most of your experience when it comes to security probably centers on designing and writing secure code. You know how to prevent buffer overflows, architect your microservices in a way that helps mitigate the impact of a breach and otherwise churn out secure application code.

But the fact is that today, knowing how to keep the application itself secure is not enough—even if you are a developer. We’re living in the age of DevSecOps, and developers everywhere are being asked to play broader roles in security at all stages of the application delivery pipeline, from code implementation through to production release and management.

With that reality in mind, here’s a look at four things developers should know about security today.

What is DevSecOps, and What Does It Mean for Developers?

Before diving into four critical things for developers to know in the age of DevSecOps, let’s take a look at what DevSecOps means.

You’ve probably heard of DevOps, an approach to software delivery that emphasizes constant collaboration between developers and IT teams.

DevSecOps extends that concept by adding security to the equation. For organizations that have embraced DevSecOps, the entire software delivery team becomes responsible for helping to secure the application. Security is no longer the exclusive domain of security engineers.

In practice, DevSecOps includes work such as integrating vulnerability scanning into the build process using tools such as Packer and ensuring that images used for deployments meet GSO guidelines. Applying OWASP’s “Security by Design” principles is also a good best practice.

What that means for developers (to put it simply) is that being a security-minded developer means more than just writing secure code. Developers must now understand security challenges and best practices at all stages of the software delivery pipeline, starting with the design and implementation of code—developers’ traditional domain—and continuing through with testing, staging, deployment and post-release management—all of which traditionally were not areas in which developers played much of a role.

This isn’t to say that developers now have to bear primary responsibility for all of the things that happen after code is written. They don’t. Their main job is still to write code. But developers should have a solid understanding of the security implications of everything that happens once they hand off code to other members of the software delivery team, to ensure they are doing their best to write code that will stay secure as it travels down the pipeline.

DevSecOps Security Lessons for Developers

If you’re a developer, the DevSecOps trend means you should now have some expertise in the following:

Microservices Security is Difficult (and Developers Can Make it a Little Easier)

Microservices architectures, which have become very common because of the agility they provide to applications, create extra security challenges that were not present in monolithic architectures. The main reason why is that microservices add many more moving pieces to an application. As a result, there are more potential security vulnerabilities within the application, and detecting those vulnerabilities can be more difficult because there is more activity to monitor.

Developers can help to address this challenge, and one way is to think about security monitoring complexity when they are deciding how many microservices to create. If developers can reduce the total number of microservices in an application without sacrificing agility, they can simplify security monitoring and enable a more secure application overall.

Developers also can make sure the microservices they write log security-related information sufficiently and clearly. You don’t want to make it more difficult for your colleagues who are monitoring an application to keep track of security events because the application doesn’t log authentication information in sufficient detail, for example.

You Can No Longer Count on Firewalls

In the days when most software ran on-premises, firewalls were a handy way of isolating applications from most security threats.

Today, organizations face a string of cloud security challenges that didn’t exist when firewalls were designed. Firewalls can still be helpful in some circumstances, but in many cases, you can no longer neatly segment applications or services off from the public internet, because you need the internet for services that are spread across a hybrid infrastructure to communicate with each other.

For developers, the lesson here is that it’s especially critical to design and write code that can resist threats that originate from the internet. Even if you don’t expect a particular part of the application to be exposed to the public internet, assume it might be, either because deployment patterns change in the future or the component is exposed without anyone realizing it.

To put this another way: Developers can’t and shouldn’t expect the IT team to be able to erect firewalls that will keep applications secure. More of the burden has shifted to developers to write applications that can resist network-based security threats because the IT team can no longer deploy firewalls like it used to.

Shift Security Testing Left

DevSecOps goes hand in hand with the mantra of shift-left testing. The latter term refers to the practice of performing tests earlier in the software delivery pipeline, rather than waiting until just before deployment to do the tests.

Shift-left testing can apply to any type of software testing, including security tests. For developers, taking advantage of shift-left security testing is a useful way of identifying security flaws within newly written code early, when they can be fixed with less effort because they have not yet been integrated into the broader application code base.

Security testing at later stages of the delivery pipeline is important, too, especially because you won’t be able to detect all security flaws until you can monitor all of your microservices as they interact with each other. But the time developers have to spend rewriting code to address security issues will be reduced greatly if their organization takes advantage of shift-left security testing.

Don’t Be Afraid to Ask for Compliance Help

A final point worth mentioning relates to compliance. Compliance is becoming ever-more challenging. And so is creating applications that meet the security requirements of compliance frameworks.

In the past, developers were often left on their own to figure out how to address compliance needs. Given the spirit of collaboration that DevOps and DevSecOps champion, however, developers should no longer feel like they have to go at it alone when it comes to interpreting and addressing compliance requirements. And indeed, they shouldn’t. If you are a coding expert, you’re probably not an expert in figuring out what complex compliance frameworks require.

The point here is that developers should not be afraid to ask for help—from legal experts, management or the IT team (which is more likely to have some experience with the compliance issues that arise once the software is in production) to make sure that the applications they design and write meet compliance requirements.

Conclusion

The developers’ main job is still writing code. But by having a greater awareness of the types of security risks that can arise within the code as it is pushed down the delivery chain, developers can do much to improve the security of the applications they write. They might even save themselves some time and headaches by reducing the number of complicated security issues they end up having to address by rewriting code.

This sponsored article was written on behalf of Symantec.

— Chris Tozzi

June 18, 2019
Building a Solid Foundation for Microservices Security

It’s often true that threats evolve faster than development practices and technologies can keep up with, which can be seen in the current microservices approach to application development. While microservices bring clear benefits to developers by enabling application deployment via modular, independently deployable services, they also open the door to new security vulnerabilities.

Consequently, these changes in the approach to software development require a change in the mindset of developers regarding how they think about and implement security. Security now must be a core component of each service—security that can withstand the constantly changing nature of these interactive services. Each service must be a resilient and secure unit that is capable of interacting with other apps and services without compromising security. In addition, each service must be careful how it handles data at the edges to ensure every possible interaction can be secured, even when interacting with services that do not meet the required security standards.

To fully address these security challenges, developers also need to change their mindset on how they approach privacy and security in their code. That means thinking of security from the genesis of the program and from within the code itself rather than relying on the infrastructure to secure the application. This approach enables developers to start their architectural decision-making by thinking of security as the foundation of their code, instead of as an accessory.

Security from the Start

In the bigger picture, DevOps teams must have full awareness and appreciation that there is no single approach to security, and that security and privacy considerations must be addressed case by case. Although there can be more, there are essentially five things that developers can do to make microservices security foundational to the development process.

Compartmentalization

First, developers must begin compartmentalizing the software development mission by attempting to make their microservices as essential as possible. Still, developers have to be careful not to go to extremes that result in the creation of a swarm of nanoservices performing a single task. The overall goal is to reduce responsibilities to the point where each single process lacks enough information to be a liability if it were to be breached.

Encryption

The role of encryption plays prominently in the new mindset for developers, so it’s imperative to utilize it on all of the data that each microservice needs and sending it on a perishable channel. This allows the cancellation of a compromised communication channel, rotation of the encryption keys used and retrying the message on a different channel or to a different node without worrying about a breach.

A good example of this is a node where control has been lost in a high availability (HA) layout. By cancelling all message queues and resending the messages with a rotated key, it’s possible to continue functioning without worrying that the unresponsive node could be compromised and avoid a full stop.

Disposable Channel Signing

Developers will greatly improve their security posture in the software development life cycle (SDLC) by sending disposable channel signing and encrypting data to the services under their control. This will allow them to cancel credentials, and avoid data leakage, even when the control on the node is lost.

Different Keys

Developers are beginning to understand the efficacy in using as many different keys as may be needed since storage is a weak point in terms of encryption. The alternative is to use keys that are rotated regularly. This, however, requires going around the persistence solution and re-encrypting a lot of the data, which is not ideal. Besides, having layers of encryption will ensure that a single leakage from the storage keys will not grant access to plain data. Also, it’s important to use different keys for storage and transport, as re-encrypting on read is easy. This process avoids the need to spread keys and keep it tight.

Key Access

Finally, developers will benefit from making sure that all keys allow the minimum possible access while keeping in mind that they will need to tailor the time to live (TTL) as much as possible to the targeted use of each key. Although this approach may result in a complex permission schema, it delivers a massive reduction of the attack surfaces while adhering to security best practices.

Conclusion

Some of this may be common sense, and what is useful for one developer might not be sufficient for another. Generally, it’s good for developers to regularly challenge these suppositions on every service that they write, but the above formulated guidelines will serve almost every developer well by providing a stable foundation on which to begin their thinking. The universal viewpoint that they should all be taking is that security must be part of the DNA of their software.

— Horacio Duran

March 27, 2018