Tag: continuous security

  • Unleashing the Power of AI-Engineered DevSecOps

    Unleashing the Power of AI-Engineered DevSecOps

    In my recent article Revolutionizing the Nine Pillars of DevOps with AI-Engineered Tools, I explained that AI-engineered tools can help implement the portion of continuous security practices known as DevSecOps.

    DevSecOps involves integrating security practices into the DevOps workflow. AI can be used in anomaly detection to identify potential security threats and to automate security policy enforcement. AI-engineered tools have the potential to significantly enhance security across all phases of the software value stream in DevSecOps.

    Planning: The planning stage involves dealing with complexities related to risk analysis and threat modeling. AI can help automate risk analysis and threat modeling based on data from past projects and known security issues. This can help identify potential security threats early in the planning phase and develop appropriate mitigation strategies.

    Design and Development (prior to integration): Developers often face difficulties in writing secure code, identifying potential security vulnerabilities, and adhering to best security practices while coding. AI-powered static application security testing (SAST) tools can automatically scan the source code for known vulnerabilities and coding errors, providing immediate feedback to developers. In addition, AI could be used to generate recommendations for secure coding practices and strategies for mitigating identified vulnerabilities.

    Continuous Integration (CI): Continuously integrating new code can introduce new security vulnerabilities and regression bugs that are hard to catch and fix in a timely manner. AI can be utilized in dynamic and interactive application security testing tools (DAST and IAST) during the integration stage. They can intelligently automate tests and identify complex security issues by analyzing data flows and the behavior of code in an integrated environment.

    Continuous Delivery (CD): Ensuring that the code is not only functional but also secure before it is delivered is a major challenge. AI-powered tools can help manage security configurations, monitor changes and alert to any deviations from security policies during the delivery stage. AI can also be used to automate security testing in pre-production environments to ensure that security standards are met before delivery.

    Continuous Deployment (to production): Monitoring, detecting and responding to security threats in real-time in production environments is a critical and challenging aspect. AI can enhance security information and event management (SIEM) tools by providing intelligent real-time analysis of security alerts generated by applications and network hardware. AI-based runtime application self-protection (RASP) tools can also detect and block attacks in real-time, providing robust protection for applications in production.

    Roadmap to AI-Engineered DevSecOps

    It’s crucial to implement AI-engineered DevSecOps solutions in a structured and well-planned manner. Here is a logical roadmap for implementing such a solution:

    1. Assessment and Planning: Begin by assessing your organization’s current DevSecOps maturity. Evaluate the existing tools and practices for their efficiency and effectiveness. Identify areas that lack automation or present security concerns. Align the AI-engineered DevSecOps initiative with your business objectives. This includes defining key performance indicators (KPIs) to measure the success of the initiative. Outline the required resources and budget for the implementation. This includes potential AI-engineered tools, the team’s skills upgrading needs and additional infrastructural changes.

    2. Selection of AI-Engineered Tools: Based on your assessment, select the AI-engineered tools that best fit your organization’s needs. This selection should cover the entire software development life cycle: Planning, design and development, continuous integration, continuous delivery and continuous deployment. The tools should ideally be scalable, easy to integrate with your existing systems and capable of providing real-time, actionable insights to your team.

    3. Training and Upskilling: Train your team on the selected AI-engineered DevSecOps tools. This may require technical training on how to use the tools effectively and how to interpret the insights generated by the AI. Upskill your team to enable them to work effectively within the new AI-engineered DevSecOps environment. This could involve training in AI and machine learning, security best practices and new DevSecOps methodologies.

    4. Gradual Implementation and Integration: Start with pilot projects to validate and tweak your approach. The lessons learned from these initial projects will be valuable for the broader roll-out. Gradually implement and integrate the selected AI-engineered tools into your existing DevSecOps pipeline. This should be a phased approach that allows your team to adapt to the new tools and practices.

    5. Review and Refinement: Regularly review the effectiveness of your AI-engineered DevSecOps implementation against the defined KPIs. Continuously refine your approach based on these reviews. This could involve adjusting your security policies, refining how you use your AI tools or providing further training to your team.

    6. Continuous Improvement: Keep yourself updated with the latest developments in AI and DevSecOps to ensure your approach remains effective and up-to-date. Continually improve and evolve your AI-engineered DevSecOps solution based on emerging technologies, shifting business objectives and feedback from your team.

    Avoiding Pitfalls While Implementing AI-Engineered DevSecOps

    Implementing an AI-engineered DevSecOps solution comes with several potential pitfalls that can derail the process if not appropriately managed. Here are a few of them, along with suggestions for how to avoid them:

    1. Inadequate Planning and Alignment with Business Goals: Ignoring the strategic alignment between implementing AI-engineered DevSecOps and overall business goals can lead to undesirable outcomes. Clearly define the business objectives and how AI-engineered DevSecOps supports them. Outline expected outcomes and key performance indicators (KPIs) that align with business goals to guide the initiative.

    2. Neglecting Training and Upskilling: AI tools can be complex, and without proper understanding and training, their deployment may not yield desired results. Invest in training your teams on AI-engineered DevSecOps tools and techniques. Ensure they understand the functionalities of these tools and how to effectively use them. Upskilling your team will be crucial for leveraging AI capabilities.

    3. Ignoring Change Management: Introducing AI into DevSecOps is a significant change that can disrupt workflows and resistance from the team members. Adopt a systematic approach to change management. Engage stakeholders from the beginning, communicate the benefits of the transformation clearly, and encourage feedback. Also, plan for a gradual rollout to help teams adapt.

    4. Overdependence on AI: Relying too heavily on AI can be a risk if the tools are seen as a complete replacement for human judgment. Recognize that AI is a tool designed to assist human decision-making, not replace it. It’s important to maintain human oversight of AI outputs, as AI models might not fully account for all contextual and situational factors.

    5. Neglecting Data Privacy and Ethical Considerations: Using AI requires handling a lot of data, which can lead to privacy breaches and ethical dilemmas if not handled correctly. Develop a clear policy for data management, ensuring compliance with all relevant data privacy laws and regulations. Make ethical considerations a priority when implementing AI, ensuring transparency and fairness in the AI systems.

    6. Lack of Continual Improvement and Adaptability: AI-engineered DevSecOps requires a culture of continuous learning and adaptation. Failure to embrace this can lead to stagnation and ineffectiveness over time. Establish a framework for continual improvement. Regularly evaluate the effectiveness of the AI tools and be ready to adapt your processes based on new technological advancements, feedback, and changes in business needs.

    Summary

    Implementing an AI-engineered DevSecOps solution necessitates a thorough and strategic approach. This begins with an in-depth assessment of your organization’s current DevSecOps maturity and an understanding of how AI can enhance each phase of the software value stream. Essential steps in the roadmap include tool selection, team training, gradual implementation, regular review and continuous refinement and learning. While AI can significantly bolster security and efficiency, it’s important to avoid pitfalls like inadequate planning, neglecting training, resisting change, overdependence on AI, neglecting data privacy and ethical issues and lack of continuous improvement. By focusing on these areas, aligning the DevSecOps initiative with business objectives, investing in team upskilling, managing change effectively, maintaining human oversight, adhering to data privacy regulations and fostering a culture of continuous learning, organizations can successfully implement and maximize the benefits of AI-engineered DevSecOps.

    Remember, this transformation won’t happen overnight. It is a continuous journey that requires regular review and improvement. With the right strategy, the benefits of implementing an AI-engineered DevSecOps solution can far outweigh the challenges.

  • How DevOps Helps With Secure Deployments

    How DevOps Helps With Secure Deployments

    DevOps is an approach to software development that emphasizes communication and collaboration between teams. It’s best known for bringing together people who previously worked in separate areas like engineering or testing; this allows them all to learn from each other as they work on projects together.

    DevSecOps helps organizations monitor and discover security risks throughout the development process rather than spending a lot on post-launch protective measures. This way, they are able to secure their product without overburdening developers with heavy-duty responsibility for what might turn out as an easy fix given time or knowledge differentials between team members—after all, they are responsible for building these things!

    The Goal of DevSecOps

    The goal of DevSecOps is to provide security best practices in a way that doesn’t disrupt team productivity.

    Secure development is the key to a smooth deployment process. It’s frustrating when you have security in your product but don’t see it being implemented or taken seriously. DevSecOps brings back that focus by reminding everyone just how important and necessary good hygiene practices are for both developers and operations.

    For security to be more effective and reliable, it should be incorporated from the very beginning. This means that instead of waiting until there is an issue or crisis before implementing measures for protection such as firewalls, encryption keys, etc.; you want your developers working on it up front so they can ensure everything will work well together later.

    It helps ensure security issues are found as early in the process as possible so it is close to decision-makers. It’s much easier (and less painful) when security issues can be fixed while you still remember what happened with your project—it’s like having an extra set of eyes on the project.

    Advantages of DevSecOps

    Security should be a high priority for any company looking to stay afloat in this digital age. From reducing risk to mitigating legal liability, identifying bugs earlier on during the project life cycle makes security management easier when things go wrong. Security becomes less painful as well since stakeholders will understand better why delays happen instead of just because “the team found issues.”

    If you shift your focus to include this earlier in the process, then costly issues can be discovered much faster and closer to where they happen, which will allow for more timely responses from developers or infrastructure engineers who must address those problems before moving on to another task.

    The goal of this system is to give Dev and Ops faster feedback on the work they are producing so they are notified right away.

    Achieving DevSevOps

    There’s no one right answer when it comes to implementing DevSecOps, as the needs of each organization will be unique. However, there are some common practices that can help to get you started.  

    Get Management Buy-In

    To make a fundamental shift in how your organization thinks about, builds and deploys software, you will need more than just peer-to-peer agreement. Management buy-in is necessary for this revolutionary change of mindset.

    The DevSecOps process is one that can help combat software vulnerabilities being exploited in production. It’s important for those who make decisions on risks versus revenue to see how this will benefit the company, or else it’ll be fruitless.

    Security is something that we should all be responsible for. It’s not just a concept or idea, but rather something tangible and real—something which can affect your company greatly if handled incorrectly by someone who doesn’t know what they’re doing. That’s why it always pays off in the end when employees take their own security concerns seriously; this will result in better decisions being made about how best to protect your assets from outside threats.

    You can’t just implement a new policy without management backing it up.

    Developer Responsibility

    DevSecOps takes security seriously by making it a part of the development process, not an afterthought. The entire team can work together to write more secure code and configurations that are robust against threats while also being easily reversible if something goes wrong—because they’re writing this stuff right from their own desks!

    It’s not just a job for security professionals anymore, either. It needs everyone from the CEO to contract workers to take responsibility for securing their own work instead of outsourcing the responsibility and expecting others to do it retroactively every time there is an attack or threat.

    Security and DevSecOps training

    There’s no quick fix for organizational culture, but it can be done. People are always resistant to change. There will initially be frustration as traditional behaviors are questioned and you create new ways of working that might not fit everyone right away.

    Managers who have a good understanding of these concepts will be able to alleviate some problems, and so will experienced engineers and other staff. It’s important for everyone involved in the process (from top executives down) to buy into this idea because it can’t succeed without their support.

    When everyone understands the DevSecOps approach, they’ll not only understand why it’s important but also see how to properly implement this new way of doing things.

    Implementing the Proper Tools and Processes

    While it is often easier said than done, getting buy-in and detecting security issues early in the pipeline sounds great. But achieving DevSecOps integration does not happen overnight, so you should start by looking at what you can do today to move this process forward more quickly.

    But there isn’t just one right way of achieving DevSecOps—every organization has its own unique methods for building software that needs to be considered when implementing these concepts across different organizations with varying cultures and workplaces.

    Key Points

    By introducing a new security component to the pipeline, DevSecOps is expanding our fundamental development and operations components with the DevOps best practices. DevSecOps is the future of software development. It ensures that security risks are monitored throughout all stages, not just after launch time when it’s too late to fix vulnerabilities and bugs before someone else exploits them for their own gain!

  • Continuous Security: The Next Evolution of CI/CD

    Continuous Security: The Next Evolution of CI/CD

    Following a wave of high-profile cyberattacks and the White House’s release of the executive order on improving the nation’s cybersecurity, how to build a successful cybersecurity program has never been so hotly debated as it is now. From SolarWinds to the Colonial Pipeline attacks, these events demonstrate that defensive measures alone cannot mitigate cybersecurity risk, and any cybersecurity program must begin where nine out of 10 breaches begin—the code. 

    The adoption of CI/CD in recent years as an extension of Agile and DevOps has enabled organizations to embrace digital transformation and ensure code is always being delivered that matches the most current business needs. Unfortunately, this has further siloed security as processes failed to keep pace. While there are a number of point solutions to address the ever-expanding domain that encompasses application security—from traditional pentesting and vulnerability scanners to monitoring of the individual components of the DevOps toolchain like containers—too many tools results in a DevSecOps “hairball” that leaves organizations inundated with data, yet without actionable information. 

    Moving Beyond Secure DevOps

    As organizations continue to evolve their delivery processes, security has found its role in secure DevOps (SecDevOps) programs to ensure the execution of security processes at every step of the software development life cycle (SLDC). By continually managing security practices, policies and debt in existing pipelines, this approach ensures that all stakeholders—from the C-suite to the developers and AppSec managers—have the information they need at every step of development to share responsibility in delivering secure software.

    However, these programs, while a good starting point, have left security requirements and checks in PDFs, Excel documents, and emails failing to capture the same benefits of security integration into the SDLC that Dev and Ops have commanded. Without SecDevOps orchestration, the information often lags the pipeline, creating new bottlenecks and uncertainty. SecDevOps orchestration gives security and development teams the confidence to know they’re following the right policies and eliminates the manual work that creates drag on the SDLC. With the automation of the application security process, enterprises get consistency and insight into their program that allows their focus to stay on shipping code while knowing it meets their organizational security standards. 

    Adding Continuous Security

    With CI/CD, organizations are able to rapidly meet the most current needs of the business as they rapidly evolve, but without a continuous approach to security as well, once again, security is siloed off. Organizations must be able to adapt their security requirements for changes both internal (changing databases, different software versions, etc.) and external (compliance requirements, changing threat landscape, etc). We need to take CI/CD one step further and also have security integrated continuously. 

    By extension, continuous security (CI/CD/CS) is the philosophy of continuously shipping software that meets the most current security standards for the business, accounting for internal and external change throughout the SDLC. 

    To effectively adopt a CI/CD/CS, organizations must focus on three key principles:

    • There is no perfect code, therefore there is no perfect security—Good application security manages cyber risk in line with overall business strategy. When you have the ability to accept risk within the risk tolerance of the businesses, you know the right times to stop, and the right times to carry on because other controls are in place. Don’t let perfection be the enemy of the shipped. 
    • Bite-sized application security—DevOps isn’t about moving fast and breaking things, it’s about moving efficiently and fixing things at the right time. Deliver the right application security information at the right time to the stakeholder responsible for executing it. This ensures better collaboration so stakeholders know where, when and with whom to direct their attention. 
    • Micro-feedback loops—Leverage orchestration to get real-time feedback on policy compliance before it creates bottlenecks down the line. This enables you to respond to changes both internal and external as quickly as possible, creating an iterative cycle of information for future decision-making. 

    By continually managing security practices, policies, and debt in existing CI/CD pipelines, this approach allows a scalable application security program to be deployed in any SDLC so it can continually evolve to always be in lockstep with today’s business.  

    Different organizations have different risks they need to account for, which means security must be aligned to business strategies and priorities in order to dynamically respond. With end-to-end integration in the SDLC, continuous security supports CI/CD to improve productivity and speed time-to-market, while reducing the risks that might impact a particular business. Software is inherently impermanent and organizations need to be able to continuously balance security, technical and business priorities to ensure they are maintaining their focus on what matters most: Delivering value to customers and shareholders. 

  • DevSecOps Will Cross the Chasm in 2022

    DevSecOps Will Cross the Chasm in 2022

    We’ve been talking about DevSecOps and shift-left security for years. Although this approach probably didn’t “cross the chasm” in 2021, we did see some very telling milestones. Cybersecurity VC funding surged to record heights with a focus on DevOps and cloud security and the need for DevSecOps became glaringly evident with the Log4j vulnerability. On a more personal note, our own open source security project Checkov has surpassed three million downloads.

    Much of this momentum was inevitable. Those in infrastructure and reliability circles have already been adopting and touting the benefits of shifting left and automating as much as possible, so in many ways, it’s expected that security would follow suit. Undoubtedly, the pandemic has also accelerated the need for developers to work more autonomously without having security personnel and processes acting as barriers to productivity and velocity.

    We’re confident that 2022 will see the silos between development and security teams continue to crumble as developer-led security practices become the norm for cloud-native organizations.

    DevSecOps finally crossing the chasm doesn’t mean that every enterprise and traditional organization will shift security left and adopt security best practices. It will, however, give them competitive advantages over those who don’t—both in decreased security costs and increased developer productivity and, thus, time-to-market.

    What else is in store for the future of DevSecOps?

    Rise of the DevSecOps Job Title

    Fewer than 5,000 people on LinkedIn currently have “DevSecOps” in their job title, yet there are over 20,000 current openings for DevSecOps roles. In 2022, expect to see more of those positions filled. This means security teams across industries will conduct fewer manual security audits, there will be a considerable influx of homegrown DevSecOps tooling and point solutions will likely begin to consolidate into single platforms. 

    Blurred Lines Between Application and Infrastructure Security

    Until recently, application security was a very well-defined (albeit fractured) space focusing on securing the custom code and open source packages that make up applications. However, with the rapid adoption of cloud-native applications, the lines between application and infrastructure security are blurring. We expect to see this trend continue as more engineers take on more infrastructure-related projects, vendors start catering to use cases outside of their core competencies (through acquisitions and in-house development) and the role of DevSecOps continues to expand within organizations.

    Infrastructure-as-Code: The Great Cloud Migration’s Next Chapter

    We’ve been talking about the great migration to the cloud for years. At this point, many companies are ready to move on to the next chapter: Infrastructure-as-code (IaC). As a result of this trend, DevSecOps will become much more important, as security needs to be baked earlier in development phases or risk being left behind. In addition, security teams will need to become more well-versed in development technologies and practices to provide the proper guidance for the new way applications are built and deployed. 

    More Software Supply Chain Attacks

    Hackers have been targeting retailers and security vendors for years, exploiting a minor weakness to gain access and move laterally into sensitive data. In the past year, however, software supply chain attacks stepped into the spotlight due to multiple supply chain attacks. We expect this trend to continue, which will, in turn, put more focus on securing supply chains. DevSecOps, which has focused mostly on tools and practices for securing the code and infrastructure, will expand to include the supply chain mechanism. 

    If 2021 was the year of hype for DevSecOps, we believe (and hope) that these best practices are embraced en masse across industries. The benefits of shift-left security are well documented: The number of high severity incidents is significantly reduced, the potential attack surface is minimized, compliance efforts are simplified and the time to remediation is lowered. Organizations also save money by catching misconfigurations and vulnerabilities earlier in the software development life cycle while at the same time gaining time back with tools, both open source and commercial, that are empowering developers to move fast and build applications that are more secure and reliable.

  • 7 Step Transformation Blueprint for SecDevOps

    7 Step Transformation Blueprint for SecDevOps

    The struggle for continuous software security is obvious, but the solutions are not.

    As I indicated in my prior blog, SecDevOps is the Solution to Cybersecurity, a security-first mindset, coupled with SecDevOps-specific practices, provides an opportunity to achieve true continuous security. But, in reality, how can an organization accomplish SecDevOps?

    This blog explains how to apply my 7 Step Transformation Blueprint to SecDevOps.

    Leadership and engineering solutions require the persistent, methodical application of skills and practices toward leading and designing solutions that achieve business and team goals, including continuous security. While driven by visionary ideals, engineering requires practical, disciplined, progressively refined implementations using carefully chosen dimensions of people, process and technology solutions. At any point in the engineering life cycle, the goal is to achieve a balanced solution while evolving practices towards maturity.

    The seven step transformation engineering blueprint prescribes seven steps for achieving and continuously refining digital transformation methodically, no matter what the goals or current level of maturity are. The seven steps are visioning, alignment, assessment, solution, realize, operationalize and expansion. Each step considers the people, process and technology aspects of the transformation.

    Step One – Visioning

    Top leaders define a strategic vision for the digital transformation for the organization including a motivating vision statement, measurable goals, team values, and major implementation tactics. Identify senior sponsors that will own the transformation at the strategic level. Include key partner organizations that need to be strategically aligned to the transformation. In a SecDevOps transformation, a vision for a security-first mindset and associated SecDevOps practices are called out as the highest priority for implementation tactics supporting the vision.

    Step Two – Alignment

    Leaders and key team members who are most important to the implementation of the transformation align specific measurable goals and tactics for selected “model” applications. Specific measurable goals around continuous security are set in this step.

    Step Three – Assessment

    For the current state of selected applications, capabilities are discovered and assessed, deep-dive assessments are conducted for specific topics, and a current state value stream map is created relative to the organization’s goals. My earlier blog, DevSecOps Practices Gap Assessment, explains my recommended approach for conducting an assessment for security.

    Step Four – Solution

    An expert team performs analysis of assessment data and formulates a future state value stream roadmap including themes, epics and user stories and obtains alignment with key stakeholders. My earlier blog, 9 Pillars of Continuous Security Best Practices, outlines a comprehensive set of practices to consider when building a roadmap for any continuous security solution.

    Step Five – Realize

    Proof of concept (POC) trials are conducted to validate solution choices. Trials of security tools and integrations of those tools into the SecDevOps platforms also would be conducted during this step. The solution is validated with selected applications and use cases. Training is conducted as the solution is deployed to production. Governance practices for the new solution are activated.

    Step Six – Operationalize

    Deployed improvements are monitored and controlled with metrics. Retrospectives are conducted to create actionable prioritized lessons learned for continuous improvement. Chris Tozzi’s article 6 DevSecOps Metrics for DevOps and Security Teams to Share suggested metrics that can be developed and leveraged, both for this step and to drive ongoing improvements as the use of SecDevOps practices expand.

    Step Seven – Expansion

    Once continuous flow (the first way of DevOps) is realized for a select set of applications, the organization can safely expand the solution(s) to other applications across the organization. Further transformation cycles will lead to realization of continuous feedback (the second way of DevOps) and continuous improvement (the third way of DevOps) and apply it to SecDevOps.

    What This Means

    SecDevOps strategies and solutions are complex. The seven step transformation blueprint described in this blog can help organizations build a strategy and implement SecDevOps as an important part of their digital transformation. To learn more about how to apply the blueprint to continuous security (and other key elements of digital transformation) refer to my book Engineering DevOps.

  • SecDevOps is the Solution to Cybersecurity

    SecDevOps is the Solution to Cybersecurity

    Anybody paying attention to world news will notice that the threats and risks perpetrated by cybercriminal actors, in many forms, is a serious problem on the rise, affecting individuals, organizations and nations daily. The cybersecurity threat space is indeed alarming and growing rapidly. The cybersecurity solution space is struggling to keep up. After all, there is no such thing as 100% security.

    What is the Solution to Cybersecurity’s Problem?

    In my opinion, the industry has long underestimated the problem of cybersecurity, which has resulted in solutions that do not sufficiently stand up to the cybersecurity threat space. What is clear is that solutions must come from rapid software changes that detect and plug security holes as fast as they are found, and continuously deploy innovative defensive solutions that keep bad actors off their guard. To do that requires Agile and DevOps continuous delivery practices coupled with a security-aware mindset.

    What is a Security Aware Mindset?

    To put things in perspective, it is useful to consider the mindsets of design, QA, operations and security.

    Design mindset – create a product or service that customers want, now. The Agile framework addresses this requirement.

    QA mindset – verify a product or service works the way customers expect it to, when it is released, for all production configurations available at the time of the release. The DevOps framework addresses this requirement.

    Ops mindset – ensure a product or service continues to work the way customers expect, for all production configurations, for the life of the product or service. The site reliability engineering (SRE) and ITIL frameworks address this requirement.

    Security mindset – defend valuables for organizations that create or use a product or service against unintended and malicious actions, by people and organizations, both inside and outside of the organizations, for all production and non-production configurations, for as long as there is something of value to protect. The DevSecOps framework was created to address this requirement; as we have seen, this does not yet offer sufficient safeguards for the growing cybersecurity threat problems.

    The security mindset has multiple additional vectors of thought required compared to the design, QA and ops mindset. This helps us to understand why the cybersecurity problem space is bigger and requires more comprehensive solutions.

    Not long ago I considered security assurance to be a subset of testing practices. In 2016, in my blog, “Seven Pillars of DevOps – Essential Foundations for Enterprise Success“, I did not break out security as a separate pillar. At that time, this type of thinking was typical of developers. Security was someone else’s job. Perimeter defenses were deemed sufficient.

    Soon after, I realized that way of thinking was naïve on my part. By the time that I co-authored a subsequent blog, “Nine Pillars of Continuous Security Best Practices,” I added a separate pillar for security specific practices, and also added security practices within each of the other pillars.

    In parallel, DevSecOps became a thing in the DevOps world. The idea of integrating security practices into DevOps makes a lot of sense, because DevOps is the answer to continuous delivery of software, and security needs continuous delivery of defensive solutions. However, simply adding security to DevOps is not a sufficient solution, because DevOps was conceived to address specific problems associated with design, QA and Ops – not security. Simply adding security as another metric for releases is not enough. What is needed is a re-think of how DevOps can be used to deliver continuous security, as indicated in my book, “Engineering DevOps.” This is the same idea behind what is referred to as SecDevOps.

    In my opinion, it is now time for SecDevOps to gain favor over DevSecOps when it comes to integrating security practices with DevOps practices. This represents a much more significant shift than simply putting security first in the name. With SecDevOps, security concerns within the entire development organization and at every stage in the DevOps value stream, are explicitly prioritized over other types of concerns. This makes sense, given the much wider blast radius of security events versus other quality concerns that DevOps was originally designed to address.

    With SecDevOps, security tools and resources are weighted at the highest priority level. SecDevOps and secure coding practices are required training for application developers. Threat modeling is part of the value stream. Security tasks that are required to mitigate security risks are given the highest priority in backlog planning. At each stage in the DevOps pipeline, security concerns rise to the top of the priority list. Release and deployment readiness are weighted at the highest level. In short, SecDevOps explicitly plugs some important security holes that are not covered by DevSecOps. With SecDevOps, security becomes continuous, not just an add-on to DevOps.

    What This Means

    By explicitly plugging some important security holes that are not covered by DevOps or DevSecOps practices alone, it makes sense for SecDevOps to now emerge as the preferred framework to close the gaps between the growing security problem space with the evolving security solution space. SecDevOps offers the required security-first mindset and solves the need for rapid software changes that detect and plug security holes as fast as they are found, and continuously deploys innovative defensive solutions to keep bad actors off their guard.