DevOps transformation can require a major shift in organizational culture and “the way things are done.” This can be difficult in any organization but gets incrementally more difficult as the size of the organization grows.
For many companies, mainly a government agency, security controls can be the main focus and one of the “reasons not to implement DevOps,” because security persons mistakenly believe handing control over to others or automating the process will abate security. Done well, it makes applications more secure. But the hurdles can be high to implement the necessary changes, especially in a bureaucracy where process and hierarchy trump efficiency.
Janek references a U.S. government report on the challenges of hiring and retaining enough security specialists, noting that 74% of agencies are “At-Risk” or higher, according to the report. No doubt, this is true across many other industries and companies. Governments also see recruiting and retention challenges because employees want to work in modern environments. Training employees is also difficult because — as we all know — it interrupts the work everyone wants to do.
Suggested Read: Automation and advantages of DevOps
Some solutions Janek covers include:
- Bake automated security into the pipeline
- Give developers and testers security tools
- Use continuous security
- Gamify training, such as code bashing
If you spent at least 10 minutes learning about DevOps, you have heard about the need to break down silos in the organization. Silos separate teams and hand-offs complicate the process. Two solutions include:
- Modeling your organization with the principles of Conway’s Law — structure an organization that resembles your goals
- Creating a platform team that offers DevOps-as-a-Service
Hesitation to Change
People naturally hate change. It is a law of nature. You can’t change that, but you can show people the value of the change so the desire to change overcomes natural resistance. Modifying culture can be particularly challenging, but it has to be done to properly implement a DevOps culture. As the famed business strategist Peter Drucker said, “Culture eats strategy for breakfast.”
What can you do to change the culture?
- Ensure sustained executive management support and a long-term vision
- Provide training, coaching sessions, etc. on tools, concepts, and concrete implementation steps, but make sure to provide them in a way that offers the least amount of interruption to the normal workflow
The Authority-to-Operate (ATO) is a specific term for the U.S. government, but the idea can be found across companies. In principle, security wants to approve an application, or even a subclass of a larger application, to operate on the system.
Also read: Successful implementation of DevOps
For example, you might need to get an ATO for a library you want to use it in your larger application. This can be a time- and resource-consuming process that can take months or even longer. It also hampers the availability of the best tools for the solution. If you can leverage cloud solutions or, even better, DevOps-as-a-Service, the ATO for these services can cover many of the items you need. This eliminates the need for separate ATOs for each application.
Secure DevOps Tools Integration
Don’t forget that your DevOps toolchain needs to be secured, too. With dozens of tools being used, each with their privileges and credentials, the security risk grows. Employing secrets management and solutions that offer integrated credentials management across the DevOps pipeline help ease the burden and tighten your security posture.
Secure the Software Supply Chain
Janek notes these days that 80-90% of an application’s code may not be your code. Commercial and open-source components help make application development efficient, but you need to take steps to ensure that code’s vulnerabilities are managed, continuously. Ensure you have tools that scan your libraries before they are used and continuously monitor applications during development, testing, deployment, and production. Also, leverage existing open-source intelligence and use tools that inject human intelligence into scans.
Featured article: DevOps and team communication
Janek and Svetlana are implementing DevOp-as-a-Service to solve the aforementioned challenges. It involves a team and a platform to continuously increase the number and scale of self-service capabilities.
Svetlana jumped into some particular of the platform, Monarch, during the presentation. Monarch is a way that GDIT formed for their government client. It is a self-service platform that development teams can use to develop Docker containers and deploy them into AWS Elastic Container Service.
Currently, Monarch has:
- Early vulnerability detection
- Quick remediation response
- Frequent updates in production are encouraged
- Multiple parties involved in security auditing