a guide to navigating devsecops
Nearly everything you need to know to make it happen!
Many federal agencies still utilize the "waterfall" method when it comes to software systems and development. One department completes a task and hands the project to the next department, who builds the next item on the list. This is the way of the past. Today's modern agency calls for the flexibility to transform software rapidly while ensuring that security tools and processes are baked into the software delivery lifecycle.
Not sure how to navigate to a DevSecOps approach? Not really sure what it is and how it fits into your modernization plans? Don’t worry. You’re not alone.
By adopting a DevSecOps mindset, you’ll set your development, security, and operations teams up for success with the right tools necessary to scale the mountain of transformational change required for your mission goals.
Still lost?
We’ll show you the way, help you maneuver around risks, and spot problems before they spot you.
Table of Contents
Introduction
Many federal agencies still utilize the “waterfall” method when it comes to software systems and development. One department completes a task and hands the project off to the next department, who builds the next item on the list. This is the way of the past. Today’s modern agency calls for the flexibility to transform software rapidly while ensuring that security tools and processes are baked into the software delivery lifecycle.
Let’s explore more.
What is DevSecOps?
DevSecOps is an evolution from the old waterfall method. It’s the pivotal response to older, bottleneck-riddled security models on the modern continuous delivery pipeline. Building and automating the development process bridges the traditional gap between IT and security while ensuring fast, scalable and reliable delivery of code. For government agencies, once-siloed teams are enhanced by increased communication and share the responsibility of security tasks during the delivery process.
In DevSecOps, normally opposing goals — speed of delivery and secure code — are merged into a streamlined system. Utilizing lean-agile practices, security testing is done in iterations without slowing down delivery cycles. Security issues are dealt with as they arise; not after a threat of compromise has occurred.
The Kessel Run Model
Known as the Software Factory that fights wars, the goal of Kessel Run was to change how the Air Force, and by extension the Department of Defense, develops and delivers software run on classified networks that adopts the best practices from the commercial industry.
The program, once though of as far-fetched, successfully demonstrated continuous delivery of software development, or in developer terms, the holy grail. It was a huge win for the Department of Defense.
Understanding the DevSecOps Pipeline
A typical DevOps pipeline includes different stages. For example, a typical software development lifecycle (SDLC) includes phase like build, code, plan, test, and deploy.
In DevSecOps, specific security checks are added in each phase.
- Plan: Execute security analysis and create a test plan to determine scenarios for where, how, and when testing will be done.
- Code: Deploy linting tools and Git controls to secure passwords and API keys.
- Build: While building code for execution, incorporate static application security testing (SAST) tools to track down flaws in the code before deploying to production. These tools are specific to programming languages.
- Test: Use dynamic application security testing (DAST) tools to test your application while in runtime. These tools actively investigate running applications with penetration tests to detect possible security vulnerabilities.
- Deploy: After completing the above tests in runtime, send a secure build to production for final deployment.
DevOps vs. DevSecOps
As agencies rethink how they develop, manage, and secure applications, DevOps—a moniker combining "development" and "operations"—is morphing into DevSecOps.
DevSecOps adds robust security methods to traditional DevOps practices from day one.
DevOps: A Critical Combination
DevOps is the collaboration between development and operations teams to create a more agile, streamlined deployment framework. It's a critical shift away from the traditionally siloed mentality of many IT teams, which prioritizes areas of specialization over communications.
DevOps has become a driving force in many forward-thinking agencies — born from the need to deliver software and services more reliably and quickly. The ideals of continuous testing and automation are essential to DevOps implementations. New deployments must be tested from the moment code is written to the hour the final product is released. Leveraging automation makes it possible to address form and function issues at speed rather than relying on outdated manual testing frameworks.
DevSecOps: Logical Next Steps
DevSecOps introduces the concept of security into the existing DevOps paradigm. It's critical to apply the notion of developing a "Security-as-code" culture that prioritizes secure deployment and speed rather than attempting to separate the two concepts.
DevSecOps integrates key security policies such as code analysis, compliance monitoring, threat investigation, and vulnerabilities assessments into typical DevOps workflows. The ideal result? Native security already built into new product deployments, which limits the risk of zero-day flaws and software recalls.
Changing Course: The Culture Shift Required
Change, no matter how it arrives, is never easy.
For government agencies, it can be even harder. Systems, processes, and mindsets are more entrenched because of the extreme vetting that goes into inputting these frameworks.
The same goes for adopting a DevSecOps approach to your software tech systems.
Bringing Government Systems into the 21st Century
The government sector, by and large, lags behind the commercial sector in software technology.
We’ve seen many a client still using the “waterfall” method, where work is done department-by-department, with no two groups actually working together on the project.
With DevSecOps, that all changes—for the better.
Your software creation and implementation becomes faster, more efficient, and more secure. Getting buy-in from stakeholders, however, can be the most difficult part of going from behind the curve to cutting-edge.
The Challenge
A waterfall approach is full of silos.
Each department works independently, with their own territory to lord over. They feel ownership over it, naturally. And when management comes in and wants to reclaim that territory or give it a different look, resistance is natural.
People worry. Will I lose my job? Can I keep up?
Management worries, too: Will this new approach actually work? We’ve done it one way for a long time—why are we abandoning our tried-and-true way? Why rock the boat?
You might be surprised how entrenched some people can be about this change. And if you believe your team is truly using a DevSecOps approach, but your development and operations teams still aren't communicating or working cohesively, you lose.
The Solution
The facts don’t change, no matter the challenge: DevSecOps will radically improve how your government agency works. Gone are the worries about security checks. The amount of time and effort saved with a continuous-integration, continuous-deployment (not delivery) environment can have a monumental impact.
Maybe that means some staffing changes are in store if you encounter persistent resistance. But when the work your government agency does is so important, it’s worth it in the long-term
Who will give you the most pushback on your journey to Devsecops enlightenment?
To fully embrace DevSecOps, you must break down barriers and foster open collaboration between development, security, and operations teams. Remember, DevSecOps is a software engineering culture.
The cultivation of shared responsibilities is vital. All DevSecOps team members must see the delivery of secure services as their responsibility, rather than something handled by other teams during development or after services are deployed.
As it turns out, not everyone in your organization may be as excited about the culture shift as you. Not everyone likes change, and there's one thing for certain, DevSecOps will bring change—how you work, what you do, how you interact with other people on the team, and beyond.
Here are five types of people or roles who might pushback against a move to DevSecOps.
- Not invented here: "Been there, done that." We've all heard this. If your management has decided that a move to DevSecOps should be undertaken—even if the existing practices have been working—there's probably been a realization that things could be more efficient, faster, and more secure.
- Losing control: People who have gained a level of experience in a particular area or domain and feel threatened by new processes. They often feel they are giving up control or diluting their expertise.
- Stuck in the middle: Middle managers are often stuck trying to balance their operations, preventing them from seeing the big picture when it comes to change. They will most likely accept something once it has been tested and proven and has reliable people backing it.
- Burned by the past: These people, who have had bad experiences or wrong incentives from the organization, have either been through too many reorganizations or think DevSecOps is another fad.
- A careful CIO: You've likely met this person. Their fiefdom is crumbling, they've been burned by previous incidents, or they've been mandated to adopt and are playing catch-up.
Field Guides: Real-world examples
Department of Homeland Security: U.S. Customs & Immigration Services
Many government agencies are behind when it comes to cloud computing and DevSecOps adoption. Not USCIS. From the top down, the agency has rebuilt its software systems with the most cutting-edge techniques and processes in the government sector. Geocent was thrilled to help them along the way.
Department of Defense: U.S. Marine corps
We were proud to be part of the OASIS team, which helped the Marine Corps transition its legacy software systems onto a brand-new, ATO platform that allows internal customers to acquire and build the software they need in a timely manner, all in a secure process. See how we did it.
Packing the Right Tools
Your toolkit for navigating a DevSecOps environment.
Systems like Git are used for tracking changes in source code during software development. They are designed for coordinating work among programmers, but can also be used to track changes in any set of files. Their goals are speed, data integrity, and support for distributed, non-linear workflows.
Learn more about version-control and options on the market.
Containers are a form of operating system virtualization. A single container might be used to run anything from a small microservice or software process to a larger application. Inside a container are all the necessary executables, binary code, libraries, and configuration files. It allows applications to run quickly and reliably from one computing environment to another.
Docker is a popular open-source container technology. Learn more about Docker features.
Tracking products like Jira or Confluence allow bug tracking and agile project management, both critical components of a software development infrastructure.
The Digital Project Manager reviewed the 10 best agile tools for managing projects.
An artifact repository manages your end-to-end artifact lifecycle and supports different software package management systems while providing consistency to CI/CD workflow. An artifact repository is both a source for artifacts needed for a build, and a target to deploy artifacts generated in the build process.
The DevSecOps artifact repository is crucial for the software development process. Without it, things can become extremely muddled, with multiple developers using different artifacts and third-party components that only slow—or completely halt—your project. Using the artifact repository can help you agency avoid testing problems and delayed releases.
A container environment, in general, encompasses your images, containers, hosts, container runtime (Docker, runC, cri-o), registries, and orchestrator. Understanding potential risks and how to protect your environment against them is essential.
Platforms like SonarQube are used to continuously inspect code quality and perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities.