DevSecOps in Federal Government

Raj Dolas is a software development veteran who has seen the evolution of programming languages. He has spent a lot of time in networking, risk management, and security. Raj spoke about a platform his team implemented in "DevSecOps: Changing the Trajectory of Cybersecurity in Federal Government." 

The DevSecOps Platform

The platform is built up of different software and environment.

The pipeline of the platform is simple and high level. Developers check in and build whenever there's a release candidate. If the build is successful, the pipeline will take the candidate to the repository. After that, the build goes through several gates: code quality, functional test, and security scan. This is to make sure that the code's quality and security are acceptable.

1. Code quality gate: This gate was built using SonarQube and some metrics developed in house. The team also implemented OWASP rules for security. The purpose of this was to ensure that the code quality and unit test coverage were acceptable.
2. Functional test gate: The functional test gate had several test suites. The first one was a simple smoke test suite. This test made sure all the libraries, RPMs, and servers were available and working. If the code passed this gate, it would go to the "must-pass" test suite. The must-pass test suite was a sub-section or a portion of all the automated tests. The purpose of this suite was to ensure that all the must-pass tests, according to users, pass the suite. There was also a manual test suite for tests that weren't automated. The testers could use this to run manual tests. Once they're done, the pipeline continues.
3. Security scan gate: The security scan gate contained web inspect for code, DB protect for database, and Tenable for some extra scans.

If the build passed all the scans and gates, it would be promoted to the next environment. The process starts with development. After development, the build goes to testing. Once the build passes testing, it goes to staging and then to production.

Usage of Platform

Raj mentions that they started small with using this platform. They deployed bug fixes within 24 hours. Starting small helped them determine the feasibility of the CI/CD pipeline and improve familiarity. Consequently, this improved their confidence and increased the use of the platform. Subsequently, it's come to a point where there are daily deployments. They also use GitLab as another option for CI/CD so they're not limited to a single DevSecOps platform. It provides more flexibility. Being a cloud-based platform, everyone can access it irrespective of where they are.

The Dos

From his experience, Raj shares the following tips:

• Get buy-in from CIOs, CTOs, and other leaders. Above all, it's important to have their support for transformation.
• Have grassroots enthusiasm.
• To have a transformation and bring change, one has to have training. So, provide training.
• Promote cultural transformation.
• Build partnership with procurement.
• Make sure your team members are accountable, responsible, and allowed to make decisions. Empower your teams.
• It's OK to fail. Learn from your failures.
• It's difficult for large federal organizations to implement change. Break down the silos and start small with pilots. Automate wherever possible. And most importantly, communicate.

The Don'ts

• Not doing all the Dos
• Assuming DevSecOps is a product. Of course, you need toolkits. However, DevSecOps is a cultural transformation. It needs to come from within the company.
• Thinking you'll succeed just by following the blueprint of someone successful. Every company is different. So, even if you take someone's blueprint, you still need to make changes that would apply to you.
• Thinking automation is a one-time thing. It's not! Things will always keep changing, so automation has to as well.
• Just following the process without actually fixing issues. Yes, processes have to be followed. But the result should be fixing the issues.

The Challenges

• Slow federal procurement, which slows down the process. In short, you need to have good rapport with the procurement team and ensure minimal delays.
• Difficulty in cultural transition.
• Strong organizational hierarchy. People are unwilling and afraid to break the existing structure.
• Difficulty having blameless postmortems. You can't have or own mistakes. Implementing DevSecOps will eventually get to blameless postmortems, but it's difficult in federal organizations.

Summing It Up

Raj Dolas tells that the way things work in small and large private sectors is different from how they work in the federal sector. The turnaround time is high, and there are difficulties bringing about change. Therefore, one must be aware of the rules and regulations of the federal sector to bring the DevSecOps culture shift.