DevOps means different things to different people. To me, it is a culture of communication and collaboration across the entire team.
In DevOps, we have a software delivery pipeline that checks, deploys, and tests every build. The goal is to give us confidence that we are producing a viable candidate for production, so we have to look at many different aspects of software quality, including security. We also have to look into functionality, maintainability, performance, and many other characteristics of our software, but if we focus on security, then we often call that DevSecOps.
How do we remember to check all those factors for every story? We define a checklist of what we want to do and test for each feature. This definition of done is a minimum—there is a subset of tasks and checks that we want to do for all stories. We don’t have unlimited time and resources to do every conceivable test before release. Instead, we have to have a baseline so we can trust that we have done enough.
Some of that baseline of trust will come from just making sure we write good, quality code. Static analysis tools will check that we are following style guidelines and best practices. Good unit tests set the expectations of how the code is intended to work. That makes maintenance easier and further builds our confidence in our software.
Our applications are made up of more than just the code we write ourselves. We rely on frameworks and libraries written by others, and we deploy on systems that are made up of packages and services. We can bolster those by making sure that they have the latest bug fixes and security patches.
And we wouldn’t be confident in our code if we didn’t at least do some security testing. We must make sure we aren’t missing obvious security holes. We need to check that we don’t allow users to do things or see data that they shouldn’t, and we have to protect and monitor our systems.
But most importantly, we have to look at each feature and assess the associated risks. Is there something about this particular change that warrants a little extra attention? Are we dealing with sensitive data, like Social Security or credit card numbers? Could this feature be used to mislead or disrupt others using our system? Do we have some way to make sure data or credentials aren’t fake or altered?
On each project, take some time to see if you have enough testing throughout your process—security or otherwise. Make sure your definition of done leads you to trust your software. A few extra checks can help you be more confident in the code you are developing.
Article originally published on TechWell Insights.
