At a high level we understand that DevOps and DevSecOps are two approaches to software development that aim to deliver high-quality products faster and more efficiently. Vanilla DevOps, I say vanilla as it is the original and it is the basic building block. It is, at its core a combination of development and operational practices, which should if, and it is a very big if, implemented correctly enable developers and operators work together throughout a project lifecycle, from planning to deployment. The principles and practices of DevSecOps are purely an extension of DevOps that integrates security into every stage of the process, ensuring that the project is secure by design and not just by verification from a penetration test undertaken postpartum.
There it is not a large leap needed to understand that the main difference between DevOps and DevSecOps is the role of security in the project design, development and deployment and ongoing lifecycle management. In DevOps, security was often treated as a separate function that was performed after the project was built and before it was released to production. This position obviously led to delays, conflicts, and even worse vulnerabilities in the application or infrastructure that has been deployed, due to security issues being discovered late in the process. This obviously required significant coding rework or a requirement to patch a deployed operating systems and core infrastructure. In DevSecOps, security is embedded into the development process from the start, and security best practices are followed by everyone involved in the project. This can result in faster delivery, fewer errors, and more secure software, as security issues are identified and resolved early and continuously.
One of the main challenges in implementing a DevSecOps strategy is the concept of shifting security left, this means moving security activities closer to the beginning of the development cycle. This is what helps in preventing security problems arising or escalating later in the process, and to reduce the cost and time of fixing them. However, shifting security left can also pose some difficulties for operational staff, who may be used to working in a traditional way where security is handled by a separate team or department. Overcoming this challenge, is coincidentally very similar to the shift needed when implementing DevOps, the operational staff will need to adopt a new mindset and culture where security is everyone’s responsibility and not an afterthought. In fact it is better to say that Operational, Security and Development teams will need to create cross functional integrated teams and which will also need to learn new skills and tooling that enables them to perform security tasks as part of their daily work.
OK, that sounds great but how do we implement DevSecOps?
This is actually a very sensible question; I mean we have been trying to correctly implement DevOps for years and that really only works in the pages of the Phoenix Project. You may or may not be surprised to find that some of the ways to implement a security shift left programme in a seamless manner acceptable to operational staff are very similar to the methods recommended to make a move to DevOps acceptable:
- You must establish a clear vision and strategy for DevSecOps that aligns with the business goals and objectives of your company. For example, if your company that wants to increase your market share and increase customer loyalty and stickiness you may adopt DevSecOps to deliver more innovative and secure products that meet customer needs and expectations.
- You must communicate the benefits and expectations of DevSecOps to all necessary stakeholders, this includes developers, operators, managers, customers, your regulators, audit staff (internal and external) and your board and SMT (Senior Management Team). For example, your company may use newsletters, webinars, workshops, or surveys to inform and educate your employees and customers about the advantages of DevSecOps and how it will affect their roles and responsibilities.
- You must provide training and education on security principles, practices, standards, and tools for all staff not just your operational staff, the Developer and Security teams will need to be re-educated about practices and procedures. For example, a company may offer online courses, certifications, mentoring programs, or hackathons to help their staff learn about security concepts such as threat modelling, risk assessment, encryption, authentication, authorization, etc.
- You should also create a collaborative and transparent environment where operational staff can share feedback, ideas, and concerns with developers and security experts and visa versa. For example, your company may use tools such as chat platforms, issue trackers, code repositories, or dashboards to facilitate communication and collaboration among different teams and roles.
- You should automate your security processes as much as possible using tools that provide code analysis, vulnerability scanning, testing, monitoring, and auditing. For example, a company may use tools such as SonarQube, Snyk, Selenium, Splunk, or Auditbeat to automate your security checks and controls at every stage of the development cycle.
- By Implementing continuous integration and continuous delivery (CI/CD) pipelines that incorporate security checks and controls at every stage, you reduce the issue of fat finger or human error. For example, your company could extend the use of tools such as Jenkins, CircleCi, Github Actions, GitLab CI/CD, Travis CI or Azure DevOps to automate the building, testing, and deployment of software with security in mind.
- You should adopt a shift-left testing in conjunction with your shifting left of security functionality to test early and test often throughout the development cycle. For example, Your company may use tools such as JUnit, TestNG, PyTest, or Mocha to perform unit testing, integration testing, and functional testing of software components, this will be expanded to integrate with your security requirements.
- You are probably using feedback loops and metrics to measure and improve the performance and quality of the software within your Development teams those processes need to be expanded out to include your security posture. For example, a company may use tools such as Google Analytics, New Relic, or Grafana to collect and analyse data on user behaviour, software performance, and security incidents.
- You must encourage a culture of learning and improvement where all staff can learn from their mistakes and successes, thereby continuously improving their security skills and practices. For example, You company may use tools such as Slack, Microsoft Teams, or Discord to create channels or communities where staff can share their lessons learned, their good practices, this tooling can be expanded to include security topics.
Summary
Hopefully we have shown that the implementation of DevSecOps is not mutually exclusive to that of DevOps as the procedures and a large proportion of the tooling sets are complementary. Moving security left and integrating it into your project lifecycles can significantly help your organization deliver better infrastructure and applications not only with a quicker return on your investment but with a much more secure posture. The end result, is that with the higher levels of collaboration, your improved efficiency, and the continual innovation driving down vulnerabilities. Your customer satisfaction will increase, they will be more trustful of your environments are they are proven secure by design and deployment. This should lead to a significant competitive advantage over your slower and more traditional competitors.
