DevOps as a practice has a long history of introducing automation, speed, consistency, and quality into an organisation's software delivery practices. However security tends to take a back seat or is an afterthought. Digital organisations today treat security as a perimeter defence problem - i.e. if you can't get into my organisation, then I'm secure.
In recent years data security has also been brought into the spotlight - mainly due to how important data has become in the digital world of transactions. In addition due to regulatory pressures like GDPR - data security is starting to take on a new interest.
This is where DevSecOps comes into focus. Rather than looking at security as an individual capability of providing network defence, or encrypting data - it allows organisations to look at their entire pipeline of delivery and understand all the security implications that arise from it.
This may not necessarily be the same depending on the organisation, and requires a holistic view and assessment of various threats.
These threats may not always be something that is commonly considered. For example let's take a look at documentation. It's not an immediate are where one would think that security is a factor - but does your organisation have guidelines for security within documents. A simple guideline could be to avoid the obvious usernames and passwords for key applications. A less obvious guideline could be to obfuscate certain aspects of a design so that if it is leaked - an attacker cannot infer enough to launch a malicious attack.
Another example is 3rd party libraries. All too often developers will use open source libraries - which greatly aid in rapid development and enhanced features. However, how well are 3rd party libraries tested? Has the developer retrieved them from a stable source? And has your organisation carried out some basic security tests targeting these libraries. The answer is probably no - and it is something to consider.
There are various examples such as this that should make security a priority. The good news is that most of these types of examples not only have tools and methodologies that allow you to secure your process and assets quickly, but DevSecOps also introduced the automation and consistency in the approach so as not to add too much of an overhead.
The reality is that security is usually an add on to any organisation, and often viewed as a laborious task, and therefore may take a back seat if it requires too much in the way of operational expenses. Unfortunately in today's world - this simply is not a level that is acceptable in the marketplace - and opens up organisations to attacks that are becoming all to familiar in the press.
DevSecOps provides an answer in that operational costs can be kept to a bare minimum through automation, and security processes can be introduced in key areas throughout the entire pipeline of an organisation's software delivery.