In my last article on the GovDevSecOpsHub, I shared with you how cultural change is necessary to make DevSecOps possible within government agencies. However, cultural change isn’t all that’s opening the door to embracing DevSecOps. There are also five essential concepts that are making it possible for application development, operations, and security teams to work together as a unit.
Here are the five concepts that make DevSecOps possible. These five things empower the changes needed for your teams to deliver solutions in a highly collaborative environment.
While each of these five plays a role in enabling DevSecOps, it is also important to note that each one needs to be continuously working as both independent and simultaneous gears. These five key components together will provide optimum visibility and maximum identification of vulnerabilities for your teams. Remember, identifying issues earlier in the development process and rectifying them quickly are keys to advancing a culture of DevSecOps.
1.Agile Project Management
Agile Project Management is an iterative approach to project management that primarily focuses on customer feedback, flexibility and effective collaboration between team members. Agile allows project teams to be more flexible and ensure that the final product is according to the end customer’s standards.
Contrary to the traditional approach, the whole team knows about the progress of the project in Agile. In this approach, the whole team decides the plan together and shares the ownership of the project which improves project transparency. Similarly, customers are also involved throughout the project and their feedback is considered for an acceptable final product.
Agile is proven to be ineffective in traditional organizations where the management is reluctant to let go of control and allow team members to make decisions. However, modern software development teams prefer an Agile methodology so the project management tool needs to reflect the ceremonies and activities of Agile.
Containers encapsulate each application with all its dependencies to allow the application to be deployed or tested in any environment and behave consistently. A developer can choose any technology or language that best meets the specific needs of the application and Operations staff do not need to be concerned with the application framework to support. With more architectures moving towards a microservices framework, containerization is a necessary underlying technology for Operations team to be able to support hundreds, if not thousands of running applications being changed rapidly.
3.Container Orchestration and Management Technology
Container orchestration and management tools function to order, schedule, place, and manage containers for execution at scale. It ensures that the containers have a reliable environment to run each service. It also provides the requisite advanced automation of management of running containers and configuring health checks to ensure their availability. Using the right container orchestration and management, Admins can now manage thousands of containers and services which would be nearly impossible for small operations teams otherwise.
Manual testing is not repeatable, can be error-prone, and takes up an incredible amount of resources (both time and money). Automated testing can test from a holistic perspective, monitoring how each service interacts with the other services, how each operates reacts under load, and measuring how successful the deployment of each service is, its resiliency, its scalability, and its security risk. Bottom line, while manual testing should still be part of an agencies overall testing strategy to ensure 100% coverage, Automated Testing should make up the bulk of the testing strategy.
Collaboration tools are services that allow interaction across the DevSecOps teams. They perform release management by recognizing all activities in the development cycle, notifying any changes and impact on the end user. And, these tools provide input and sign-off as the services and application are developed in real time.
All input is visible to the whole team and is traceable. This creates a level of transparency and accountability required for the culture of DevSecOps environments. As I mentioned in the last article, technologies/tool sets empower and enable the methodology. GitOps, ChatOps, and Pipelines are examples of elements found within collaboration tools.
As we go about our work in a DevSecOps environment, culture and technologies work hand-in-hand to help you meet your clients’ needs. Neglecting either aspect would be to the detriment of the end user. I am hopeful that by illustrating the need for both that your DevSecOps environments will continue to be evermore streamlined and effective.