As someone who’s worked within the Information Technology (IT) sector for two decades, I’ve observed many teams battle with slow, siloed and generally dysfunctional software development systems. This is often because their teams don’t have a strategy that allows them to work in a streamlined manner. Implementing a DevSecOps environment is a great way to resolve this. I’d like to share what to consider when you want to start building your own DevSecOps pipeline.
What is DevSecOps?
Initially, there was DevOps: Development and Operations. DevOps is an iterative process of managing the Dev and Ops teams that emerged from Agile software development. Thereafter, Security (Sec) was added to the DevOps process to create the DevSecOps environment. Techies refer to this environment as the DevSecOps ‘pipeline’.
The Sec is included with Development and Operations as a way of emphasising that security must be taken seriously by being included in the DevOps pipeline from start to finish. The primary goal of the DevSecOps pipeline is to allow the Secure Software Development Lifecycle (SSDLC) to run as autonomously and efficiently as possible.
Before DevSecOps the Dev, Sec and Ops teams were disjointed and mostly treated as separated teams or departments without a procedural pipeline. Furthermore, the Sec team was often a single ‘Tom’ or ‘Stacey’. This disjointedness would often lead to ad-hoc and failed attempts to deploy solutions and applications. This ultimately boiled down to the loss of productivity, affecting profitability and potentially credibility of the organisation.
DevSecOps has the potential to resolve these challenges by creating a more streamlined approach to projects and service delivery.
Note: The security part of DevSecOps is baked into the entire pipeline, so I will refer to the DevSecOps pipeline as the DevOps pipeline. However, I will make specific reference to DevSecOps when talking about security aspects.
DevOps pipeline value
The agile, iterative nature of DevOps allows for continuous integration (CI), continuous delivery (CD), continuous deployment (CD), and continuous monitoring (CM). The ‘continuous’ aspect means that changes happen throughout the process, which results in fewer challenges later on. For example, an early detection of code issues, security challenges, and operational inadequacies means less time and effort spent later on.
Another key benefit is automation. This means that less time is spent on operating or maintaining the environment in which the solution or application is in, allowing the team to spend more time on actual solution development and optimisation. There are more benefits and value-added points, which you can check out here.
Two scenarios where a DevOps pipeline could be beneficial are as a startup or an established organisation. For example, as a startup, you’re still in the process of constructing your IT infrastructure. Put another way, you are ‘putting the lego pieces together' for your new and recently implemented processes and workflows. In this environment, it would be a good idea to automate as much as possible, so that once the startup starts scaling, there aren't too many challenges or ‘teething problems’ around growing manual processes. As an established organisation, postponing the automation transition within the Development, Security, and Operations teams will only lead to more challenges and setbacks during development and operations, which take up time and resources. Automation frees up resources to be used for other tasks.
In other words, implementing a DevOps environment within your organisation will prevent human error and resource wastage.
How to get started with DevOps in your team
Fusing people from two or more different teams can be hard. In my experience, there is a lot for people to learn when different contexts are brought together: Setting up a DevOps environment means you are fusing together separate ways of working, with separate approaches to problem solving and communication, and that will take time to get right.
Set your team up for collaboration
You need to set your team up to allow for collaboration and ensure team buy-in.
A collaborative platform allows the team to work together more efficiently and effectively. Examples of collaborative tools include Google suite, Redmine, Asana, Jira, Trello, and Slack.
Additionally, setting up a room, even if it is an always-on Zoom room, where the team can work next to each other sets them up to communicate quickly and easily. It’s a good way to get people used to each other when embarking on something new.
Start small
When starting out, it’s important to start small. Starting small while you’re still figuring things out means you won’t waste resources on things that might not work out. When narrowing down your focus, think about what will add immediate value to you and your team, and then focus on solving those problems.
To do this, take the processes you need to fix and break them down even further. Once you’ve broken them down, map out your solutions for each issue. This provides you with a basic idea of what your DevSecOps pipeline would need, and should be based on your team’s and business requirements. After this you can begin with developing your pipeline and look further into technologies to help you do this.
You cannot build everything out at once in your DevOps pipeline. In other words, the next stage or component in the pipeline depends on the successful implementation of the previous stage or component of the pipeline.
These components are illustrated in the diagram above. Therefore, to successfully implement, for example, the Code Quality Analysis component, you need to make sure the Source Code Management component has been successfully created. Due to the nature of the DevOps pipeline, you have to start small to progress.
Design your DevOps environment to work for your team and the problems you’re facing
You need to design your DevSecOps environment based on the gaps in your team. For example, if you have problems with code merge and integration issues, your big problem is retroactively spending time and effort on code problems. Your pipeline needs to focus on tools that detect code problems early on, such as QA, testing and integration tools. See the DevOps pipeline components above for examples of the tools referred to. I’ve added many examples for tools, because tools need to be chosen according to what works for your team. There isn’t a one size fits all solution.
What components go into designing a DevOps environment and how do they fit together?
There are numerous components that go into designing and building a DevOps environment. Going through the details of each and every one is beyond the scope of this article, however, I will introduce the components and provide examples. These are the foundational components and tools that you can use to build your DevOps environment. Once you have these in place, you can build on them. See the resource list at the end for more detail on setting up a DevOps pipeline.
As mentioned earlier, the DevOps environment is also referred to as the ‘pipeline’. Think of the pipeline as different components that need to receive data, services or instructions from the component before it, and provide data, services or instructions to the component following it. The image above paints a picture of this pipeline.
The large peach and green rectangles are components that incorporate technologies or tools used to create the DevOps pipeline.
The white rectangles containing just text are the tasks performed within and alongside these components. These tasks form part of the DevOps pipeline workflow.
A DevSecOps pipeline consists of various components, which are the foundation of building your pipeline. After your components, you also have workflows, which are the processes that happen within and alongside the components. To create workflows, one completes specific tasks to ensure the DevOps pipeline progresses.
The Framework is also known as the CI/CD framework. In other words, the technology or tool that allows the Dev’s code, the Sec’s security integration, and the Ops’ infrastructure and scripts to be ‘managed’, i.e. DevSecOps. Think of the framework as the ‘orchestrator’ that allows all these mentioned components with their tools to ‘talk’ to one another.
Tool examples: Jenkins, GitLab CI, TeamCity, Travis
Source Code Management is used to store the code the development team creates in a central repository. The task one performs within this component is checking out and building code, which is part of the CI process. This allows the code to be continuously integrated into the pipeline when required. For example, the developers are done with some code and then they push it into the code repository manager. The Framework component detects the change and processes it through the pipeline.
Tool examples: Git, Mercurial, Subversion.
Build Tools are used to build the code into the desired format for cleaning, compiling, testing, packaging and deploying the software. Here, you can make sure your code is functioning as required, which falls under the task of building code and unit testing.
Tool examples: Maven, Ant, Gradle, Cake, Grunt.
Code Quality Analysis helps to improve code quality, and keeps the codebase relevant and updated. This part of the pipeline makes up code testing coverage, which generates reports to evaluate existing code for improvements. This part of the workflow, quality control and fetching latest builds, ensures we stick to code quality standards.
Tool examples: Cobertura, SonarQube.
Testing Frameworks help write and run the code tests and are part of code test coverage. The corresponding task for this component is integration testing, which makes you ask the question, “Is the service operating as expected after the merging of individual features?”
Tool examples: JUnit, Selenium, Cucumber, Pytest
The Store Valid Binary Packages component incorporates the task of packaging and archiving. Here you get the services and applications ready for deployment, and store resources such as libraries. Some applications can depend on tens or hundreds of external libraries: For example, a web application with many JavaScript or jar file dependencies. Usually, these are stored in an external repository. In other words, outside of your pipeline. However, these binaries and packages can also be stored within the pipeline as an internal repository manager, contributing to efficiency and team performance by not having to rely on external resources which could be altered or removed altogether.
Tool example: Nexus
Configuring Management and Deployment Tools include automating configurations, using scripts to generate reporting and monitoring, and deployment-related tasks. The corresponding tasks for this are fetching release-ready builds, acceptance testing, and deployment to the relevant environment. This enables you to prep the services for deployment and get approval from stakeholders before going live. Furthermore, this is where you’d push the services and applications to the deployed infrastructure.
Tool examples: Puppet, Chef, Ansible
The Deployment Environment is where the applications are eventually deployed. It’s the infrastructure that allows the team to host their solutions and applications. The task this involves is hosting services, which makes the solutions and applications available to the end-user.
Tool examples: Docker, Kubernetes, VMWare, Azure
The Sec in DevSecOps
At this point, you may be wondering where the Sec part of DevSecOps is. Well, this omission was intentional. Once you understand the DevOps environment, then the Sec in DevSecOps is easier to understand. In other words, you saw the tool examples for each component. Similarly, for the Sec part of DevSecOps, the components will have Sec tools for them, where relevant.
Sec works across components, and sometimes between them. The important thing to remember is that it should always be part of the DevOps pipeline. It’s as simple as that!
Examples of these Sec tools are:
Threat modelling
Tool examples: Mozilla Rapid Risk Assessment
This tool is implemented in the planning stage of the DevSecOps environment. In other words, before entering the pipeline with source code management.
Static application security testing (SAST)
Tool examples: Veracode, SonarQube, Raxis
The SAST tools tend to be used earlier in the DevSecOps pipeline during early builds, such as in the Build Tools component. In addition, SAST tools can and should be used throughout the pipeline. It can be used during integration and acceptance testing, and production releases.
Dynamic application security testing (DAST)
Tool examples: Burp Suite, Sqlmap, SSLScan
The DAST tools tend to be used during integration and acceptance testing of the service or application. It simulates real-world attacks acting as a malicious hacker trying to hack the system. The DAST tools may also be used during production. However, this is often not the preferred approach.
The DevSecOps environment is not easy to navigate, let alone create. I’ve tried to paint a more vivid picture of its implementation and show that the DevSecOps environment, with its merged teams, is a mesh-up of various software, tools, packages, libraries and environments that acts as a single ‘orchestrated’ environment. This enables the DevSecOps team to automate many of the previously manual processes within development and operations, providing higher quality to the client more efficiently with resilience. This is the DevSecOps pipeline.
Some DevSecOps Resources:
https://www.ibm.com/za-en/cloud/learn/devsecops
https://www.redhat.com/en/topics/devops