The Developer’s Compliance Survival Guide
As developers, we don't love thinking about compliance. But it's getting more and more important. Here are some tips to remain agile.
Join the DZone community and get the full member experience.Join For Free
So your team is adopting yet another compliance framework. Maybe somebody else is calling the shots, or maybe you even got the (not so fun) job of leading the charge yourself. While it may seem tempting at first, you simply cannot outrun compliance these days. It really is up to you to survive compliance, keeping your software development work agile and fun.
So how to go about that?
First of all, start by educating yourself about compliance and cyber-security. While nobody is expecting developers to be experts on the topic, a basic understanding of the terms and implications can go a long way in enabling you to have a voice.
Compliance exists in many fields beyond cyber-security and software development, but it all boils down to the same thing - governance. To achieve compliance, an organization must be able to demonstrate that processes are carried out and decisions are made according to a prescribed set of guidelines to mitigate certain risks.
Since time immemorial, software development security principles have stayed the same - the “CIA Triad”:
Confidentiality: protecting data from unauthorized access and misuse.
Integrity: protecting data from unauthorized modification, preventing initiating unauthorized actions within the system.
Availability: protect timely and uninterrupted access to data and processes for authorized users.
Obviously, cyber-security goes well beyond that, and it’s worthwhile to learn a bit more about the basic risks and protections. Based on your preferences, there are endless resources including books, blogs, videos, online courses, and even hands-on training (check out Secure Code Warrior).
When the time comes, and compliance starts imposing new requirements on the software development lifecycle (SDLC), be sure to understand them. As a software developer, you should own up to poor security and compliance practices, just like you own up to poor quality code and products.
The last thing you want to do is to have your production-ready application go through a blackbox of tests that may or may not clear if for production. Quite the opposite, you should build your software development process to root any potential risks or issues.
To maximize application quality, we have adopted a plethora of testing strategies and automation tools. To ensure code-quality we execute planning sessions, deploy linters, and utilize code reviews. For ensuring security and compliance deploy tools such as software composition analysis (SCA), static and dynamic application testing (SAST/DAST).
As you gradually become more compliant, certain environments will be moving out of reach. Many systems such as those serving production traffic, or processing and storing real data, will become restricted. Fewer people are going to have access, and even that access will be more strictly controlled.
This inevitably means that you are going to have to spend more time and effort ensuring that you have the data you need to understand what’s going on in those remote environments. Ensuring that you have high-quality logging, metrics and tracing in-place will definitely help. And as you can never get monitoring perfectly right, having a remote debugging tool available will make sure you can fill in any blind spots in the blink of an eye.
As developers, many of us don’t find it particularly fun or interesting to deal with security and compliance concerns. But the fact of the matter is that, as developers have grown in power and influence, so has their responsibility set. DevSecOps is no longer just a buzzword. More and more, we are being tasked with not only the reliability and performance of our software but also that it is compliant and secure. Be curious and read as much as you can, embrace shifting left, and invest in tools that give you instant access to data.
Opinions expressed by DZone contributors are their own.