This article is based on a piece originally published on helpnetsecurity.com. The concepts and framework described below reflect widely discussed DevSecOps principles.
The Afterthought Problem: Why Security and DevOps Have Always Clashed
Consider the automotive industry for a moment. Safety engineers don’t bolt airbags onto a finished car as an afterthought. They design crash protection into the vehicle from the first sketch on the drawing board. The result is a vehicle that looks seamless, feels comfortable, and meets rigorous safety standards—without the manufacturing line grinding to a halt every time a new model ships.
Application security has historically worked nothing like this. For decades, development teams built software, handed it to a security team at the end of the cycle, and waited while that team attempted to retrofit controls onto a finished product. Under the old six-month release cadence, this friction was inconvenient. Under modern continuous delivery, it is a fundamental blocker.
DevOps is engineered for constant, rapid change. Traditional security practices treat change as an inherent threat. The result is a painful trade-off: either slow down the pipeline so security can catch up, or keep shipping and ask the security team to sort things out later—possibly after a vulnerability is already in production.
DevSecOps: Embedding Security as a First-Class Citizen
The DevSecOps model addresses this by integrating security teams, tooling, and controls directly into the DevOps workflow. Rather than acting as a gate at the end of the pipeline, security functions are distributed across every phase: planning, development, testing, deployment, and operations.
When security is embedded this way, it stops being a speed bump and becomes part of the standard build process—analogous to unit tests or linting checks that run automatically on every commit.
However, team integration alone is not sufficient. One persistent bottleneck has been the manual writing of security rules for each new application deployment. When a release is ready to ship, security engineers have historically needed to hand-craft policy rules from scratch—a slow, error-prone, and frustrating process that undermines the speed gains DevOps promises.
Intent-Based Security: Moving Beyond Manual Rule Writing
A newer approach called intent-based security reframes the problem. Instead of writing individual rules for every asset or deployment, security teams define the intent behind their policies—what assets exist, how they should communicate, and what risk posture is acceptable. From that intent, rules can be automatically generated and applied to any new deployment.
This approach acts as an abstraction layer. Both security professionals and non-security stakeholders (application owners, line-of-business leaders) can participate in policy enforcement without needing to write syntactical rule strings by hand. Machine learning and automation handle the translation from human-readable intent to machine-enforceable policy.
Establishing Security Intent: A Three-Step Framework
Before rules can be auto-generated, security teams must first establish a clear picture of security intent. This involves three steps:
1. Inventory and Analyze Assets
You cannot protect what you cannot see. Recursive network indexing builds a comprehensive inventory of assets on the network. Traffic flow analysis and access path analysis then reveal how those assets actually behave—what they communicate with, what protocols they use, and what access patterns are normal versus anomalous.
2. Classify Communications Protocols
Not all protocols are appropriate in all contexts. For example, protocols such as SMB (Server Message Block) or Telnet may be entirely inappropriate between certain asset classes in a modern environment. By classifying protocols and pairing them with asset types, security teams can create meaningful profiles: for instance, “this asset class is never permitted to initiate a Telnet connection.” If a deviation from this intent appears on the network, it signals a policy violation immediately.
3. Overlay Business Context
Raw network data and protocol classifications are meaningless without business context. A database server communicating with an internal analytics platform is very different from that same server communicating with an external IP address at 3 AM. Business context—what applications do, who owns them, what data they handle, and what regulatory requirements apply—transforms data points into actionable security intelligence.
Translating Intent into Policy: Key Considerations
Once security intent is established, the next challenge is translating that intent into enforceable policy. Three categories of input must be considered:
Compliance Requirements
Regulatory frameworks such as PCI DSS, HIPAA, or SOC 2 impose specific controls on specific asset types. These compliance requirements must be mapped to concrete access controls and rules. Intent-based security makes this mapping explicit and auditable, rather than buried in tribal knowledge.
Business Requirements
Business goals are typically expressed in plain English—”only authorized sales staff should access customer PII” or “the payment service must never communicate directly with the public internet.” With traditional approaches, engineering teams translate these goals manually into rule syntax specific to each enforcement device or platform. Intent-based security uses automation to perform that translation, allowing rules to be dynamically generated as business requirements evolve.
Security Mandates
Security mandates change as new vulnerabilities are discovered or threat landscapes shift. When a mandate changes—such as deprecating a weak cipher suite or blocking a newly identified attack vector—intent-based systems propagate that change automatically across all relevant rules and deployments, rather than requiring a manual update across dozens of individual policies.
The Practical Impact on DevOps Pipelines
When rules are automatically generated from templates derived from security intent, the DevOps pipeline gains several concrete advantages:
- Faster deployments: Application teams no longer wait for security engineers to hand-craft rules before a release can proceed.
- Consistency: Automatically generated rules are applied uniformly, eliminating the human error that accompanies manual rule writing.
- Auditability: Intent is documented and traceable, making compliance audits significantly less painful.
- Self-service policy application: Application owners can apply pre-approved security templates themselves, with security teams retaining oversight through template governance rather than direct rule authorship.
- Rapid response to change: When security mandates shift, policy updates propagate automatically rather than requiring a manual review of every existing ruleset.
Security by Design, Not by Bolt-On
The automobile analogy is instructive precisely because it illustrates what good looks like. When safety is designed in from the start, it becomes invisible to the end user—it just works, and it doesn’t slow down the factory floor. Intent-based security automation aims to achieve the same outcome for software delivery: security controls that are integrated so smoothly into the pipeline that they add negligible friction while providing robust protection.
Eliminating the friction between DevOps velocity and security rigor is no longer optional for most organizations. Automated rules generation—grounded in clearly defined, context-aware security intent—is one of the most promising mechanisms available to make that happen. As DevSecOps matures from a buzzword into a standard operating model, teams that invest in intent-based approaches will be better positioned to ship fast and ship securely.