devopsy.kinsta.cloud

Tag: secops

Future Proofing the Foundation for AI-Ready Security Operations
Last December, the International Telecommunication Union (ITU), the United Nations’ (UN) body for information and communication technologies, supported Open Cybersecurity Schema Framework (OCSF) for ratification as an international standard by June 2026. Standardization is now a global necessity as governments worldwide integrate ITU standards into their national cybersecurity policies.

First, What is OCSF?

The OCSF provides a standardized approach to streamline security operations, improve threat detection, and accelerate incident response. This unlocks the full potential of security data. A standardized schema for security events normalizes data from various sources, which creates a unified foundation for advanced analytics and AI-powered tools. This standardization is crucial for unleashing the full potential of generative AI in cybersecurity, allowing organizations to better identify patterns and correlations across disparate data sources.

Data Standardization is Crucial

Security is fundamentally a data problem. Modern enterprises generate security logs across on-premises data centers, cloud environments, and SaaS applications. This wealth of information should accelerate detection and response, but inconsistent log formats create friction. When each security tool uses a different schema, engineers spend time building data pipelines and custom parsers instead of developing advanced detection algorithms. This slows investigations and hampers the ability to leverage AI-powered security operations.

Standardized schemas enable AI systems to correlate events across sources, identify patterns, and generate accurate insights. This gives models consistent, unambiguous data to reason effectively. OCSF provides that foundation: an open source standard that automatically normalizes security data from any source into a common language, creating AI-ready data without custom parsers or complex pipelines.

OCSF Turns Data into Agentic Security Operations

The key to this transformation was OCSF’s standardized schema, which enabled efficient queries that weren’t possible before. Security investigations previously required learning different log formats, developing complex queries for each data source, and manually decoding output into meaningful information. With OCSF, an orchestrator coordinates child agents that automatically retrieve relevant runbooks, pull business context, analyze logs without format translation, and generate actionable insights. The AI doesn’t misinterpret data because OCSF provides consistent attribute definitions, unambiguous data types, and standardized query paths across all log sources.

OCSF provides a universal format that removes hours of manually stitching logs from different services together. Beyond improving data quality, OCSF gives AI systems the consistent language they need to reason effectively. This shifted security operations from reactive analysis to intelligent, automated response. The future of security isn’t about hiring more analysts. It’s about empowering the analysts you have with AI systems that understand their environment.

From Emerging Standard to 1.8.0

The OCSF community continues to evolve the framework to meet emerging security challenges, while maintaining strict backwards compatibility. Since the last update at Black Hat 2025, the community has released v1.8.0 (released March 16th, 2026), with enhancements focused on AI operation observability, network packet-level visibility, and privilege analysis.

Key enhancements in v1.8.0 include:
- AI Operation Support: A new ai_operation profile and supporting objects (ai_model, message_context) bring native schema coverage for AI workloads, including token usage metrics and role-based interaction tracking.
- Privilege Analysis with ATT&CK Mapping: New objects (privilege_info, privilege_attack_info, service_privilege_analysis) enable detailed privilege analysis with MITRE ATT&CK technique mapping, supporting unused privilege detection and access risk assessment.
- macOS Extension and Cross-Platform Improvements: A new macOS extension adds egid and euid to the process object, with related attributes promoted from the Linux extension to the base schema for cross-platform reuse.
- Network Packet Capture: A new packet object on network event classes enables packet-level data representation, along with a network_observation_point attribute for richer traffic context.
These enhancements reinforce OCSF’s role as the schema for AI-ready security operations, extending native coverage to the AI workloads and network telemetry that modern detection and response demands.

Getting Security AI-Ready

The security industry is entering a new era where AI-powered security operations become the norm rather than the exception. Agentic AI scales the traditional SOC model, where analysts manually triage alerts, investigate incidents, and respond to threats, to meet the velocity and complexity of modern attacks.

Standardizing security data allows organizations to build the foundation for autonomous threat hunting and investigation, predictive vulnerability analysis, and intelligent response orchestration.

As governments worldwide incorporate ITU standards into national cybersecurity frameworks, regulated industries, like they have with other standards, will lead OCSF adoption.

Additionally, OCSF maintainers have initiated collaboration with OpenTelemetry (OTEL) maintainers to integrate security and observability domains. Unifying security telemetry with operational telemetry enables holistic analysis: understanding what happened, why it happened, and what it means for the broader system.

This new landscape brings parity to adopters. AI is transforming security operations, and OCSF is how organizations future proof security data for this transformation.
March 24, 2026
Intelligent Continuous Security From the Platform Outward

In today’s fast-paced software delivery world, platform engineering has emerged as the backbone of scalable development. Internal Developer Platforms (IDPs), golden paths and paved roads have become the essential building blocks for enabling developer productivity. But as platforms mature, the next frontier is clear: Security must be native to the platform itself, not an afterthought.

Enter Intelligent Continuous Security (ICS), an AI-driven, end-to-end security paradigm that unifies DevSecOps and SecOps across the entire software lifecycle. When implemented from the platform outward, ICS has the power to deliver seamless, secure software without slowing teams down.

Why Security Must Be Platform-Native

Traditionally, security has existed outside the platform — governed by SecOps teams, enforced through static policies and often applied reactively. In the DevSecOps era, we began embedding security into the CI/CD pipeline. But even that approach relies heavily on developer action, separate tools and manual triage.
That’s not scalable. When security is treated as a service delivered through the platform, it becomes consistent, invisible and scalable. ICS is not just about adding security features — it’s about transforming the platform into the delivery vehicle for secure-by-default development.

ICS + Internal Developer Platforms: A Perfect Match

IDPs give developers self-service access to infrastructure, CI/CD, environment provisioning and templates. By embedding ICS into this experience, organizations can:
• Abstract security complexity – Developers shouldn’t need to know every OWASP top 10 risk or compliance control. ICS-powered templates and pipelines encode best practices automatically.
• Provide secure defaults – Pre-approved base images, configuration-as-code, and least-privilege access are pre-baked into golden paths.
• Orchestrate proactive scanning – AI-enabled tools can monitor every stage, from pull request to production, for vulnerabilities and anomalies.
The platform becomes the primary enforcement and observability layer, making secure development frictionless.

Golden Paths as Security Enablers

Golden paths (or paved roads) are curated workflows that guide developers through preferred ways to build and ship software. When ICS principles are embedded into these paths, you get security that scales:
• Static and dynamic analysis baked into templates
• Secrets management, logging and compliance hooks are integrated by default
• AI-driven threat modeling at service creation time
• Monitoring, alerting, and rollback pipelines are auto-wired for every deploy
This moves security “left and right” simultaneously, ensuring security from idea to runtime, without requiring developers to piece it together themselves.

Real-World Anti-Patterns: What Happens Without Platform-Based ICS

Let’s look at common breakdowns when ICS is not built into the platform:
• Shadow pipelines – Teams bypass security because the “official” path is too slow or cumbersome.
• Inconsistent tooling – Different teams choose their own scanners, rules and remediations, creating visibility gaps and risk inconsistency.
• Slow incident response – Without feedback loops or automated detection, runtime issues take too long to identify or fix.
• Developer burnout – Security becomes a burden rather than an enabler, adding friction at every stage of delivery.
Without ICS, security remains fragmented, manual and slow — precisely the opposite of what platform engineering aims to solve.

Feedback, Observability and Adaptive Defense: ICS in Action

ICS relies on real-time observability, AI-powered analysis and adaptive threat modeling. Here’s how those work when implemented through the platform:
• Continuous Monitoring: From code to cloud, behavior is analyzed in real time. Unexpected patterns trigger investigations before they become incidents.
• AI-Assisted Feedback Loops: Every production incident informs future builds. If a misconfigured container leads to a breach, the next platform release updates templates to prevent recurrence.
• Self-Healing Infrastructure: Smart pipelines can trigger rollbacks, isolate systems, or patch automatically based on AI-driven risk scores.
• Contextual Threat Modeling: When a developer requests a new service, the platform suggests risks based on architecture, data sensitivity and known threat patterns.

This is not speculative. The ICS model would have significantly improved defenses in three high-profile attacks:
• SolarWinds: Continuous behavior monitoring could have identified abnormal build behavior and external command-and-control patterns early.
• MOVEit: ICS threat modeling would have surfaced file-transfer components as high risk, flagging them for higher scrutiny and faster patching.
• Log4j: Runtime monitoring and AI-powered dependency analysis would have accelerated detection and helped prioritize exposure for remediation.

Building the ICS-Enabled Platform Team

Platform teams must go beyond infrastructure abstraction and productivity enablement. They must own the delivery of security as a product.

This doesn’t mean platform engineers become security experts — it means they:
• Collaborate closely with security teams on templates, policy-as-code and feedback loops
• Integrate security scanning, threat modeling, and observability into the platform
• Treat AI-driven security tooling as core platform capabilities, not optional add-ons
• Enable self-service for compliance and security controls
With ICS, platform engineers help deliver security at scale, the same way they deliver Kubernetes clusters or CI/CD workflows.

The Path Forward: From Fragmented to Intelligent Security

SecOps was the first step. DevSecOps moved security left. But Intelligent Continuous Security, driven from the platform outward, is the only sustainable model for secure software delivery in the AI era.

Here’s what organizations can do today:
1. Evaluate your internal platform – Are security features baked in or bolted on?
2. Unify DevSecOps and SecOps tooling – Create single, AI-powered pipelines that span build to runtime.
3. Empower your platform team – Make security a first-class platform concern, and give developers golden paths they can trust.
4. Invest in observability and feedback – Use AI to close the loop from production to development.
5. Think from the platform outward – Secure defaults, smart automation and adaptive risk modeling should start at the platform level and scale with delivery.

In the end, ICS is not a tool—it’s a philosophy of secure software delivery. When it begins with the platform, everything else aligns: Speed, safety, and scale.

April 30, 2025
Bridging the Dev and SecOps Gap: How Intelligent Continuous Security Enables True End-to-End Security

DevOps has revolutionized software development by emphasizing speed, agility and collaboration. However, security has often been an afterthought, introduced late in the software delivery pipeline. This traditional approach leads to bottlenecks, compliance headaches and increased security risks. The rise of DevSecOps attempted to bridge this gap by embedding security into development workflows, but even DevSecOps has struggled with friction between development, security and operations teams.

Intelligent Continuous Security (TM) (ICS) is the next evolution — harnessing AI-driven automation, real-time threat detection and continuous compliance enforcement to eliminate these inefficiencies. ICS extends beyond DevSecOps to also close security gaps with SecOps, ensuring end-to-end continuous security across the entire software lifecycle. This article explores how ICS enables true DevOps transformation by addressing the shortcomings of traditional security, reducing friction across teams, and accelerating secure software delivery. For a deeper dive into ICS, explore my O’Reilly book Intelligent Continuous Security.

The Security Bottleneck in DevOps

As indicated in the article The Next Generation of Security “The Future of Security is Continuous. Security isn’t a destination — it’s a continuous process of learning, adapting and evolving. As threats become smarter, faster, and more unpredictable, security must follow suit.”

Traditional security practices were designed for a slower, waterfall-style development process. Security reviews, vulnerability scans and compliance audits were performed at the end of the development cycle, often delaying releases and frustrating DevOps teams. The key problems include:
• Siloed Security Teams – Security is treated as a separate function rather than an integrated part of the software development lifecycle (SDLC).
• Manual Security Processes – Static security reviews and penetration testing require time and resources, creating bottlenecks.
• Reactive Security – Most security strategies rely on detecting and fixing issues after deployment, increasing the risk of vulnerabilities in production.
• Compliance Delays – Meeting regulatory requirements often involves manual documentation and audits that slow down release cycles.

Two high-profile incidents — SolarWinds and Log4j — highlight the catastrophic risks of inadequate security integration. The SolarWinds supply chain attack exposed the dangers of late-stage security testing, while the Log4j vulnerability revealed the widespread impact of unpatched, legacy software components. These incidents underscore why organizations must move toward Intelligent Continuous Security.

How Intelligent Continuous Security Removes Friction

Intelligent Continuous Security (ICS) builds on DevSecOps principles but goes further by embedding AI-driven security automation throughout the SDLC. ICS creates a seamless security layer that integrates with DevOps pipelines, reducing the friction that has long plagued DevSecOps initiatives. Key benefits include:

AI-Driven Threat Detection and Prevention
ICS leverages AI and machine learning to detect vulnerabilities and misconfigurations in real time. Unlike traditional static security testing, AI-driven analysis can continuously scan code, dependencies and infrastructure for security risks, identify and prioritize vulnerabilities based on real-world exploitability, and automate remediation suggestions, reducing the burden on developers. For example, AI-powered security tools like Snyk, Lacework and Deep Instinct proactively analyze software for potential threats before they make it into production.

Security as Code for Automated Compliance
ICS introduces Security as Code, embedding security policies directly into development pipelines. This ensures that security policies are automatically enforced across CI/CD workflows, compliance audits are streamlined with real-time security controls and infrastructure-as-code (IaC) security is validated before deployment. By integrating tools like Open Policy Agent (OPA) and HashiCorp Sentinel, organizations can codify security policies that continuously enforce best practices without manual intervention.

Continuous Security Testing and Shift-Left Security
ICS shifts security testing left by embedding automated security checks at every stage of development. This includes Static Application Security Testing (SAST) during coding, Dynamic Application Security Testing (DAST) in staging environments, Software Composition Analysis (SCA) to detect vulnerabilities in open-source components, and Runtime Application Self-Protection (RASP) for real-time threat mitigation in production. These automated security controls reduce the reliance on late-stage security reviews, enabling faster and safer releases.

Seamless Developer Experience
One of the main criticisms of security in DevOps is that it disrupts developer workflows. ICS changes this by embedding security directly into developer environments with Integrated Security Plugins – Security scanning tools integrate with IDEs like VS Code and JetBrains, providing instant feedback on vulnerabilities, Developer-Friendly Security Insights – AI-driven recommendations help developers remediate issues without relying on security teams and automated secrets management – preventing credential leaks with tools like HashiCorp Vault and Doppler. By making security intuitive and developer-centric, ICS eliminates the common friction that slows down DevOps teams.

Real-World Examples of ICS Enhancing DevOps Workflows

The SolarWinds Sunburst attack demonstrated how security blind spots in the software supply chain can lead to widespread breaches. Had ICS been in place AI-driven anomaly detection could have identified suspicious activity earlier, continuous security testing would have flagged vulnerabilities before deployment and automated threat response could have mitigated the impact before it spread.

The Log4j vulnerability highlighted how unpatched software components create long-term risks. ICS would have automatically identified affected applications in real time, recommended immediate remediation steps using AI-driven analysis and enabled continuous patching and compliance tracking to prevent similar issues in the future.

These incidents emphasize the need for a proactive, AI-driven security approach that ICS provides.

Conclusion: ICS as the Future of DevSecOps and SecOps

The DevSecOps movement was a step in the right direction, but many organizations still struggle with integrating security into DevOps workflows without slowing down innovation. Intelligent Continuous Security (ICS) represents the next evolution, removing friction through AI-driven automation, continuous testing and policy enforcement while closing security gaps between DevSecOps and SecOps.
By embedding security deeply into DevOps pipelines, ICS enables:
✅ Faster, more secure software releases.
✅ Seamless collaboration between development, security and operations teams.
✅ AI-powered threat prevention and real-time remediation.
✅ A future-proofed security strategy that evolves with modern threats.
As DevOps adoption continues to grow, ICS will be the key differentiator for organizations seeking to achieve true DevOps transformation without sacrificing security.

Next Steps:
If your organization is struggling with security bottlenecks in DevOps, now is the time to explore
and The Next Generation of Security: Intelligent Continuous Security.

March 13, 2025
Survey Surfaces Spike in Generative AI Usage Across IT

A survey of 800 DevOps and application security operations (SecOps) leaders published today found nearly all (97%) are making use of generative artificial intelligence (AI).

Conducted by the market research firm Sago on behalf of Sonatype, the survey found that beyond writing code, a full 45% of the 400 security operations professionals have already embedded generative AI into their workflows compared to 31% of the 400 DevOps professionals.

Security operations teams also reported greater time savings than their DevOps counterparts, with 57% saying generative AI saves them at least six hours a week compared to only 31% of DevOps respondents that saw the same benefit.

The top benefits cited by security operations teams is increased productivity (21%) and faster issue identification/resolution (16%) compared to faster software development (16%) and more secure software (15%) cited by DevOps professionals.

It’s still early days as far as embedding generative AI in workflows is concerned, but it’s clear the ability to write code faster is trumping concerns about the increased number of vulnerabilities that might find their way into application environments. The most widely used generative AI platforms are trained on a massive corpus of data that includes code of varying quality. As such, a lot of the code generated by a general-purpose AI platform will likely have as many errors, including vulnerabilities, as the code used to train it.

The level of faith organizations will place in that code will be heavily influenced by use cases. A script used to automate DevOps workflows that are not externally facing may be one example of where a general-purpose AI platform can boost productivity. In other instances, code that contains vulnerabilities that find their way into a web application might be much more problematic.
Despite those concerns, however, the survey finds nearly three-quarters (75%) of all respondents feel pressure to use generative AI.

There are, of course, already large language models trained on code that has been vetted by software engineers. In the months ahead, the code generated by AI platforms specifically designed for that purpose should significantly improve.

Sonatype CTO Brian Fox said it’s only a matter of time before IT organizations focus more on ensuring the generative AI platforms are tuned for specific tasks. In the meantime, however, application security may get worse before it gets better, with more than three-quarters of DevOps respondents noting that generative AI will result in more vulnerabilities in open source code. Only 58% of security operations professionals are similarly concerned.

It will be up to the engineers that make up these teams to bring discipline to code quality practices and make sure the code running in a production environment is of high quality, regardless of how it was created, noted Fox. For the moment, the issue is that AI augmentation is now occurring at a faster pace than the AI advances that should one-day help DevOps teams cope with increasingly larger codebases, he noted.

Survey respondents are also concerned about who might own the code generated by AI. A total of 40% said developers or the organizations they work for should own the copyright for AI-generated output, and most of them agreed developers should be compensated for the code they wrote if it’s used in open source artifacts in LLMs (DevOps 93% versus SecOps 88%). A total of 42% of DevOps respondents and 40% of SecOps respondents said a lack of regulation could deter developers from contributing to open source projects.

DevOps and SecOps leads both want more regulation: Asked who they believe is responsible for regulating the use of generative AI, 59% of DevOps leads and 78% of SecOps leads said both the government and individual companies should be responsible for regulation.

At this point, the proverbial generative AI genie is out of the bottle, so there is no going back. The issue that remains to be seen is how DevOps and security operating teams will adjust to that new reality.

September 12, 2023
3 Ways to Achieve Faster App Development Without Compromising Security

Bringing products to market quickly, efficiently and safely is key to brand success, and elite DevOps teams minimize the lead time for changes by quickly and efficiently moving new products and software updates from concept to deployment. DevOps teams often measure lead time in hours, not days, weeks or months, which underscores the centrality of speed in today’s hyper-competitive online environment. Customer experience and brand loyalty are constantly changing as new products and services come to market, and DevOps teams are under immense pressure to stay as agile and efficient as possible. Increased technology development velocity can lead to heightened security risks. As of early 2023, as many as nine out of 10 companies have detected security risks in their software supply chain. This is why companies cannot ignore the rising number of attacks targeting software development teams.

High-profile incidents at SolarWinds, NetBeans IDE, Kaseya and Codecov demonstrate the risks facing software development teams at every company.

These threats exploit the continuous integration and continuous delivery (CI/CD) process to sneak harmful software into authentic applications and install risky and harmful components whenever possible.

The risk of code injections makes safeguarding internal and external dependencies crucial. If not appropriately protected, compromised software pipelines can lead to data leaks, code tampering and system exploitations, putting the entire business at a heightened risk.

Simply put, DevOps teams must maximize development speed without compromising security. This is an undoubtedly tall order, but one that’s achievable with the right processes in place. Here are three strategies DevOps teams can implement immediately to reach this goal.

Streamline Privileged Access Management

Streamlining privileged access management is vital for enhancing cybersecurity in DevOps teams, particularly with the growing threats to software supply chains. This requires adopting stringent security practices, including temporary access permissions that can be granted and revoked as needed—a strategy ideal for managing temporary services in DevOps workflows.

This approach facilitates automatic management of access privileges, including revoking password permissions when team members leave the organization or project and thorough scrutiny of who has access to what.

At the same time, enforcing least privilege access, a principle that aims to minimize the attack surface by eliminating unnecessary permissions and adjusting overly broad ones, is also essential, reducing the chances of account hijacking or theft of static API keys.

Similarly, zero standing privileges are also essential, relying on just-in-time access management that ensures minimal active permissions at any given moment, enhancing security by reducing potential vulnerabilities.

Leverage AI Solutions for Security

The cybersecurity AI sector is soaring alongside escalating cybersecurity threats to DevOps teams.

Deloitte expects cybersecurity AI solutions to become a $19 billion market by 2025, as the technology’s “ability to adaptively learn and detect novel patterns can accelerate detection, containment and response, easing the burden on SOC analysts and allowing them to be more proactive.”

AI can help DevOps teams detect and prevent cybersecurity incidents by quickly identifying and monitoring applications at risk, ensuring greater resilience in their DevOps processes through CI/CD, applying analytics to streamline data challenges, and identifying potential hot spots before they escalate and present real risks.

AI can also help combat alert fatigue within security teams, reduce analyst workloads and cut down on false positives, saving valuable time. According to a 2022 IT industry study, 60% of respondents receive more than 500 cloud security alerts every day, and alert fatigue is “causing critical alerts to be missed at an alarming rate.”

By leveraging AI for cybersecurity, DevOps teams can enhance their defensive posture without diluting their team’s impact, allowing them to best balance speed and security in the app development process.

Enable Communication and Collaboration in DevOps Teams

In the realm of DevOps, success relies not only on implementing the right tools and technology but also on fostering an adaptive culture that encourages seamless communication and collaboration among team members.

Effective communication forms the bedrock of this cultural shift. By establishing clear lines of communication, development and operations teams can better understand each other’s challenges and perspectives. Open dialogues can foster mutual respect and create a shared understanding of common goals, thereby encouraging a collaborative problem-solving approach.

Meanwhile, fostering a collaborative culture is equally vital. When teams collaborate effectively, they can identify and resolve issues more quickly, improve the quality of the software, and accelerate delivery times.

Embracing Speed and Security in App Development

Achieving faster app development without compromising security is a complex yet achievable goal in today’s competitive environment.

By investing in streamlining privileged access management, leveraging AI and fostering a culture of effective communication and collaboration, DevOps teams can enhance both speed and security.

To be sure, in the face of escalating cyberthreats, speed and security are not mutually exclusive but, rather, two sides of the same coin. By implementing these strategies, DevOps teams can navigate this delicate balance, accelerating development timelines while ensuring robust security.

September 7, 2023
SecOps: The Next Stride for DevOps
Global IT spending is now touching a figure of $4 trillion. In today’s technology-intensive environment, data is the biggest commodity, more valuable and powerful than ever. And like Peter Parker’s uncle Ben noted, “With great power comes great responsibility.”

Security has always been a big concern for valuable things and IT is no exception. IT as a whole is trying to push security left in the development cycle—trying to involve it in every step of the development cycle. And just when development and operations teams are getting used to the “esprit de corps” we call DevOps, I think it’s time we add the third musketeer: security.

What is SecOps?

SecOps is a collaboration between security and operations teams, just like development and operations teams collaborate on DevOps front. SecOps is a set of practices organizations need to follow, processes they need to execute and tools they need to use to ensure the security of their application environment. SecOps is making sure organizations do not sacrifice security to attain set performance and uptime indexes.

In a typical development cycle—requirements gathering, design, development, testing, implementation or deployment and maintenance—security normally is introduced in the later stages, somewhere between testing and deployment or even later. But SecOps is all about making sure to introduce aspects around security much earlier or at each stage of the software development life cycle (SDLC).

I know what you are thinking: This is going to complicate things and increase the time to delivery. This is where operations and development teams need to join forces to uncomplicate the things and make it time efficient practice. Next thing you must be thinking of is, Why so much hassle? Think of it the other way. Wouldn’t it save more time when you address the security concerns at much earlier stages than at the time of delivery or implementation? All it takes is an amalgamation of the security group, development team and operations team; a little bit of planning; and a whole lot of execution.

SecOps + Containers

Containerization is slowly but steadily moving from an alternative to full virtualization to a serious platform for running your applications. Containers have some obvious advantages including scalability and flexibility, and this solves most of the problems related to resources in case of application development. Reduced size; reduced time to provision application environment and testing; platforms including Docker, Solaris Zones, BSD Jails; and orchestration platforms including Kubernetes, CoreOS Fleet, Amazon ECS and OpenShift make containers a more preferred option for application development environments.

This increased traction toward containerization points to the increased need to concentrate on security aspects. Here are some best SecOps practices for container environment you and your organizational teams can follow:
- Authentic sources and images: Always check for authenticity of container images. There are various tools such as Docker’s security scan. With Docker Cloud and Docker Hub you can scan images to check for potential security vulnerabilities. Most images are built from some base image and not built from scratch, so there is always a threat with the used images.
- Vulnerability management tool: There are tools available in the market to analyze container image formats and libraries for threats before you actually start using them.
- Follow benchmarks and hardening guidelines: Always make sure you do the checks and follow hardening guidelines for containers, images, hosts and platforms before you start with production. There are few standards and benchmark checks for containers such as CIS’s Docker security benchmark, PCI compliance checklist, etc.
- Periodic auditing: Regular auditing of your application environment can help you save yourself from the future troubles. Moreover, automation of auditing process can help in detection of unused images and containers.
- Use of management frameworks: Use frameworks that can automate behavior profiling and control all the users, authorize the access to the containers, images and hosts.
- Security built in to container engine systems and third-party security solutions: Third-party vendors have a number of applications for container security in addition to security systems of container management platforms.
Dev + Sec + Ops

With the continuously increasing business demands for new applications and software, and new practices and development trends such as DevOps, Agile, cloud, automation, CI/CD and others, traditional security needs to upgraded in the new paradigm. Thankfully, some of these practices facilitate the security. Consider CI/CD as an example: Continuous integration requires continuous integration tools, or what we call build servers. Some popular examples are Jenkins, TeamCity, GitLab CI, Travis CI, Bamboo, Go CD, CircleCI and Codeship. The best SecOps practice is to check and fix vulnerabilities at early stages as a part of CI/CD workflow. Integration between authentication, scanning, management tools and CI/CD pipeline tools could be the best possible solution to your security-related problems. Some easy-to-implement solutions can include automated security testing, static code analysis, authentication checks and login tracking.

SecOps enable organizations in lifecycle management, analysis of security threats, incident management, optimizing and measuring the effectiveness of security controls, reduced breach response time, reduced security risks and increased business security. The basic principle on which SecOps works is Avoid, Analyze, Respond, Review, Repeat. By analyzing the security events and data, you can build incident response plans to avoid future unwanted events.

Frameworks and Tools

Now that you have a clear understanding of why you need your security, development and operations teams to work together, let’s see what tools and frameworks you can use.
- Docker-native tools: If you are using Docker as a platform then you can use few security tools provided by Docker itself for the security of production environment: Docker Bench and Docker Notary. Docker Bench is a script that checks common best practices around deploying Docker containers in production. Docker Notary enables you to check whether content is from a trusted publisher.
- Chef: Chef provides different tools including Inspec to automate security testing.
- Puppet: Puppet provides security compliance and policy defining frameworks.
- Ansible: Ansible provides system tracking, setting up firewall rules, user lockdown and compliance automation solutions.
- CoreOS Clair: CoreOS Clair is an open-source project for vulnerability analysis in applications and Docker containers.
- SaltStack: SaltStack can help in orchestration and automation of security practices solutions for containers.
This is just a look at some of the most popular ones. If you want, there are a number of others that can look after the security of your application environment.

The main motive behind implying SecOps practices in any organization is involving security team at all possible stages to remove any ambiguity in any stage of development rather than security team providing analysis reports to the operations team and then sitting back and enjoying the show. When these teams perform in a synergistic manner, the business focus can be shifted to other important things.

About the Author / Chaitanya Jawale

Chaitanya Jawale is founder and CEO of Opcito Technologies, a leader in microservice-based product engineering and automation. Chaitanya comes with strong background in product engineering, data center automation, DevOps and multi-cloud orchestration and management.
August 14, 2017
Everything Ops: Are DevOps Principles Being Applied Too Broadly?
From big data to storage to security, the DevOps concept is being applied to every field of IT operations under the sun today. This “Everything Ops” movement reflects the popularity of DevOps—but is it also diluting DevOps’s significance?

DevOps itself focuses on software delivery. It’s about designing, building, testing, deploying and managing software applications.

If you follow the DevOps conversation, however, you know that DevOps principles are now being extended to lots of niches that don’t have much or anything to do with software delivery chains. Consider these examples:
- DataOps: DevOps principles for data analysts.
- ChatOps: The idea that chat tools should be integrated into workflows.
- SecOps (or rugged DevOps, or DevSecOps, or whatever else you want to call it): DevOps practices for security teams.
- Storage Ops: The insertion of DevOps practices into storage.
The list could go on. Taken together, these many flavors of DevOps reflect what I like to a call an “Everything Ops” tendency. Fans of DevOps want DevOps to take over the entire world of IT.

Benefits and Drawbacks of ‘Everything Ops’

If you believe that DevOps represents a better way to deliver software, then the Everything Ops movement is a positive thing. It’s a way to help people who work in areas of IT other than software delivery to innovate as well by taking cues from their DevOps colleagues.

But there is also a danger that Everything Ops can be applied too broadly. You can’t fit every single thing in the IT universe into the DevOps mold. For example, CloudOps (the DevOps-related way of managing cloud infrastructure, not the company of the same name) just doesn’t make a lot of sense. It’s basically just a reiteration of the ideas that are already at the core of cloud computing: Scalability, agility and location-agnosticism.

Concepts like ChatOps can also be problematic because they refer to a specific way of using a particular type of technology, whereas DevOps is about cultural practices. ChatOps is a fundamentally different sort of thing from DevOps.

Conclusion

In short, by overextending the DevOps conceptual framework, you run the risk of diluting the importance of DevOps itself—and of losing your focus on software delivery, which is the area that DevOps benefits most.

This is not to say that we shouldn’t extend DevOps to other fields. We certainly should. But we should be careful when doing so. Don’t try to make DevOps eat the entire IT world, because that just doesn’t make sense.

— Chris Tozzi
January 17, 2017
Are We Leaving Developers Out of DevOps Spinoffs?

SecOps. DataOps. NetOps. Reading these terms, you get the sense that the key to IT efficiency is to make IT Ops work with everyone else. But that’s a mistake, because it leaves developers out of the picture.

It’s no secret that the DevOps movement has generated a number of other *Ops initiatives, including those listed above. The driving idea behind all of them is that IT Ops teams should work more closely with security teams (in the case of SecOps), data analytics teams (in the case of DataOps) or networking teams (in the case of NetOps). These are only a sampling of *Ops movements; the list could go on.

To be sure, there are advantages to gain by having IT Ops collaborate more closely with other parts of the organization. But there are an equal number of advantages in doing the same thing with developers.

To optimize security operations, you need developers, IT Ops and the security team to work together. If Dev is left out of the picture, it’s much harder for the other two parts of this equation to make sure that the code the organization deploys and manages is secure.

For similar reasons, DataOps, NetOps and almost all the other *Ops you can come up with work well only when Dev also participates. The people who actually design and write the applications are important.

Rethinking Ops

Why does this matter? My point is not merely that terms like SecOps and DataOps are misleading because they don’t mention developers.

On the contrary, giving equal weight to developers is important because if you don’t, you risk isolating developers. Some are already complaining that DevOps is “killing” them. The trend of defining new *Ops practices that don’t mention developers is not helping.

So, maybe we should start mentioning and thinking about developers more prominently when we are talking about ways to extend the DevOps philosophy to other parts of the IT organization. This is already being done somewhat in the case of SecOps, which you sometimes hear called SecDevOps. But Google lists nearly 13.5 times as many results for “SecOps” as for “SecDevOps.” The numbers are similar if you search for “NetOps” as compared to “NetDevOps.” And I’ve never heard anyone say “DataDevOps.”

The takeaway is this: Developers are as important as IT Ops to DevOps. Don’t leave them out.

— Chris Tozzi

November 15, 2016
Top 5 DevOps Practices to Improve Security in Engineering
We’ve all been there … A new application or feature needs to be deployed yesterday and the last thing anyone wants to do is address security requirements. On the flip side, the very last thing anyone wants to address later is a security breach or a cost associated with non-compliance. Not only is it a massive headache but also it’s extremely expensive. According to the IBM X-Force Threat Intelligence Report 2016, the average cost of a data breach in 2015 was $154.20 per record ($363 per healthcare record) with the average total cost of a breach estimated at $3.79 million.

Not only is a breach expensive in terms of cost that can be easily quantified, but there are also costs that are harder to quantify such as the impact to branch image and customer loyalty. According to a new FireEye research report, 76 percent of respondents would likely take their business elsewhere due to negligent data-handling practices. In an incredibly competitive technology space, none of us can risk turning a blind eye to security if we want to attract customers with cool new features and then keep those customers with trust and reliability.

Security seems to be one of those topics that you either love or hate. I’m personally interested in it; however, I realize it’s not an interest shared by all. In the land of unicorns, we want all developers (infrastructure and application) to have more ownership in security, but tight schedules combined with the lack of expertise and reliable controls often can make that strategy unreliable. To make matters worse, a secure system and application isn’t something that is always glaringly visible to an end user or product owner. As a result, security may easily get deprioritized as something that “can be fixed later.” The “fix it later” strategy can be a dangerous decision, as many cybercriminals now are actively taking advantage of those that deploy quickly without adequate controls. How do you balance the customer’s desire to have new features delivered quickly with the fact that they need secure systems protecting their data against malicious threats?

Several common DevOps practices inherently lend themselves to providing a development and delivery pipeline that can improve your overall security posture. DevOps combined with SecOps includes practices that shift operational and management aspects of a system to the left to ensure we are able to reliably delivery and manage secure systems.

5 Security Practices Worth Considering

Below is a list of the top five DevOps practices and tooling that can help improve overall security when incorporated directly into your end-to-end continuous integration/continuous delivery (CI/CD) pipeline:
1. Collaboration
2. Security test automation
3. Configuration and patch management
4. Continuous monitoring
5. Identity management
If you iteratively build in security practices as you move infrastructure and application code through the deployment pipeline, it greatly increases your security posture as well as decreases the cost of future rework.

Collaboration and Understanding your Security Requirements

Many of us are required to follow a security policy. It may be in the form of a corporate security policy, a customer security policy and/or a set of compliance standards (ex. SOX, HIPAA, etc). Even if you are not mandated to use a specific policy or regulating standard, we all still want to ensure we follow best practices in securing our systems and applications. The key is to identify your sources of information for security expertise, collaborate early and understand your security requirements early so they can be incorporated into the overall solution.

Security Test Automation

Whether you’re building a brand new solution or upgrading an existing solution, there likely are several security considerations to incorporate. Due to the nature of quick and iterative agile development, tackling all security at once in a “big bang” approach likely will result in project delays. To ensure the project keeps moving, a layered approach often can be helpful to ensure you are continuously building additional security layers into your pipeline as you progress from development to a live product. An example of building gates in as you progress through your pipeline is shown below. Security test automation can ensure you have quality gates throughout your deployment pipeline giving immediate feedback to stakeholders on security posture and allowing for quick remediation early in the pipeline.

Configuration Management

In traditional development, servers/instances are provisioned and developers are able to work on the systems. Sometimes there is a “golden image” developers use to provision that can ensure that the provisioned servers/instances have a hardened operating system. However, as soon as any additional development and configuration activities happen on those servers, that server is no longer golden. To ensure servers are provisioned and managed using consistent, repeatable and reliable patterns, it’s critical to ensure you have a strategy for configuration management. Your strategy may include Chef for one situation, Salt for another situation, immutable infrastructure, or a combination of practices. The key is ensuring you can reliably ensure and manage consistent settings across your environments.

Patch Management

Similar to the concerns with configuration management, you need to ensure you have a method to quickly and reliably patch your systems. Missing patches is a common cause of exploited vulnerabilities including malware attacks. Being able to quickly delivery a patch across a large number of systems can drastically reduce your overall security exposures.

Continuous Monitoring

Ensuring you have monitoring in place across all environments with transparent feedback can alert you quickly of potential breaches or security issues. It’s important to identify your monitoring needs across the infrastructure and application, and then take advantage of some of the tooling that exists to quickly identify, isolate, shut down and remediate potential issues before they happen or before they become exploited. Part of your monitoring strategy also should include the ability to automatically collect and analyze logs. The analysis of running logs can help identify exposures quickly. The collection and analysis of security logs can identify issues that require remediation as well as provide automatic collection of compliance evidence. Compliance activities can become extremely expensive if they are not automated early.

Identity Management

DevOps practices help allow us to collaborate early with security experts, increase the level of security tests and automation to enforce quality gates for security and provide better mechanisms for ongoing security management and compliance activities. While painful to some, it has to be important to all if we don’t want to make the headlines.

We are all busy keeping up on everything that is emerging in technology and it’s difficult to keep up on all of the latest issues, so relying on reputable tools and reliable sources of information can be extremely beneficial. Some of my favorite resources in this area are The OWASP and SC Magazine. IBM X-Force is another great reliable resource to check out for the latest threat research and services. There are also a slew of tools out there to help with different areas of security in each of the practices covered in this blog. I’d love to hear about some of your favorites at @Shelbee_SE.

About the Author / Shelbee Smith-Eigenbrode

Shelbee Smith-Eigenbrode is a senior software engineer/IT architect at IBM and has been in IT for 19 years. She has worked across varying roles spanning the software development life cycle. Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices. She is a member of the IBM Academy of Technology committed to driving innovation and technical advancement.
September 12, 2016
Murphy’s DevOps: Is Security Causing Things to Go Wrong?

“Rugged DevOps,” “DevSecOps”—am I missing any? About the only thing more abundant than the volume of terms emerging to describe different facets of how security supports DevOps are the number of vendors now claiming to provide products and services that “solve” related security problems.

There have been some interesting offerings we’ve seen emerge at this point and most of them probably have merit, in that they likely can accomplish the job they claim to do. Regardless of whether that “job” is actually something that needs to be done to solve a DevOps-related security issue, that is something for the professionals in the developer, operations and security worlds to determine—and hopefully something they will be interested in discussing here.

This new column’s point is to go looking for problems and solutions. Specifically, it’s focused on how and if DevOps is causing things to go wrong in security (and from time to time in other spots) and what DevOps-focused organizations are doing to correct course.

Security Questions to Ponder

Is it true that security can’t keep pace with “continuous?” Will “agile” and security always be oil and water? Will DevOps and security never achieve a harmonious “peanut butter and chocolate”-like relationship? Or, is the talk about how DevOps is the best thing that has ever happened to security and a great opportunity, actually the new reality?

Another great question this column seeks to answer is whether any of the “so-called” security problems DevOps is creating are anything new, or if they are the same old challenges that have existed since the first bit of sensitive data was exposed to the Internet decades ago.

There are times when I may mention specific vendor solutions in this column, but only if an actual end user or practitioner is attached to the reference. If that happens, I will always point out if any are clients of mine at my day job.

It’s no coincidence that this column is being launched just ahead of RSA 2016, as DevOps Connect: Rugged DevOps @ RSA Conference is a major part of the big show, and, that is where the world will be talking DevOps and security after all. Here’s hoping the event will expose problems and provide solutions.

February 29, 2016