Imagine this, your developers are all huddled together in their section of the office –  typing their hearts out as they create lines and lines of code;, security is drafting the latest policy (and Steve from accounting  will be quite upset when he  realizes that he can no longer plug in a USB drive into his work laptop, for “security reasons”).  Additionally, the operations folks are busy triaging tickets (Jill still doesn’t know if the ticket that she worked on last week was due to user error or a defect that was missed in testing).

Each department is only focused on their direct task.  To amplify the dilemma, departments only interact with each other when code is getting ready to be deployed into production. Security is now screaming at the development team for hard coding passwords into the application; operations is upset because they were asked to test new functionality at 4:55PM on a Friday, and the development team is tired of being unable to release new code into production because it needs to be reviewed. Everyone in the office is exhibiting stress, efficiency is at an all-time low, and it appears as though everyone has forgotten how to communicate with each other. If only there was a framework that could be used to address these issues! Well, have no fear, DevSecOps is here!

Before we question the concept of DevSecOps, we need to explore previous approaches to software development so that we can understand why this approach is so advantageous in the modern world. In the initial stages of software development, departments were free to work in their own diminutive bubble, since development cycles would last for months, or even years. Imagine having to wait an entire year for your favorite app to update!  Ordinarily, in some corporations, departments did not know what tasks other departments were engaged in until it was time to decide if the new feature should be introduced to the end user.  Moreover, if there were any objections, each team would essentially have to start from the inception, again. Those days, and that type of approach, are long obsolete.  Consequently, if companies want to supply dispense products in a truly agile manner, departments that were once isolated must now work in partnership to continuously release new products and functionality to customers.

Now that we have some historical framework, let’s describe DevSecOps and why organizations should implement it. DevSecOps is a framework/mantra/cultural shift that focuses on holding everyone accountable for security. It allows for security choices to be made at the same scale and speed of development and operational decisions. Teams work closely together and constantly communicate to ensure that requirements are well-defined and that issues are resolved in the beginning of the software life cycle – versus the end – thus, avoiding the need to abandon a project and restart from the beginning. While some individuals tend to focus on the technical tools required to implement DevSecOps, such as: collaboration software, automated scrips, and so forth, it is important to note that these tools still require teams to communicate effectively with each other. An organization can purchase the most extreme, cutting-edge testing software; nonetheless, if employees do not understand the client’s fundamentals, they have essentially created a subpar product.

Forcepoint.com has outlined a typical DevSecOps workflow:

• A developer creates code within a version control management system.
• The changes are committed to the version control management system.
• Another developer retrieves the code from the version control management system and performs analysis of the static code to identify any security defects or bugs in code quality.
• An environment is subsequently created, using an infrastructure-as-code tool, such as Chef. The application is deployed, and security configurations are applied to the system.
• A test automation suite is then executed against the newly deployed application, including back-end, UI, integration, security tests and API.
• If the application passes these tests, it is deployed to a production environment.
• This new production environment is monitored continuously to identify any active security threats to the system.

By bringing development, security, and operations together, issues can be identified earlier, communication and collaboration can be improved, and decisions can be made promptly.

Interested in learning more about DevSecOps? Contact us and we’ll be more than happy to answer your questions.