The DevSecOps movement promotes a “shift-left” approach where security scans begin at the first commit and continue throughout the pipeline and beyond. Automation is pervasive and threats need to be identified and mitigated early and often. Developers are now tasked to write, build, secure, deploy, and potentially operate their own code.
Fueled by the two-year pandemic, today's remote workforce has increased the need for heightened security awareness in all aspects of the business. This is particularly true for those who work in the technology sector. The use of new tools, coupled with decreased control over the remote working environment, adds extra layers of complexity. We need DevSecOps today more than ever.
While we can solve some of these challenges through active automation, we cannot fully realize the benefits of DevSecOps without internalizing DevSecOps principles. DevSecOps is a way of thinking, of awareness, and certainly of behaving. DevSecOps requires a security mindset from developers, security professionals, site reliability engineers (SREs), and business staff.
[ Want a shareable primer on DevSecOps and its benefits? See What is DevSecOps? ]
Automation is a necessary element, but organizations cannot buy their way into DevSecOps without human acceptance of their personal responsibility for security. Shift-left is as much a human initiative as a technical one.
The human side of DevSecOps
The mantra “security is everyone’s responsibility” must be backed up with cultural shifts in collaboration, communication, mentorship from security specialists, and training in order for humans to engage. A successful DevSecOps culture focuses on collaboration instead of competition. Teams need to align by using and understanding the same vocabulary and practices.
Policies around cyber hygiene in remote environments must be supported with guidelines on daily behaviors that can offset the risk of data breaches and malware. The tenets of DevSecOps should be communicated and visible so that people feel part of the solution and empowered.
1. Build security across all phases
While most arguments around whether security should be part of the application development process can be put to rest, discussions about where security should be included continue. In some organizations, security is part of the beginning – for example, in the initial phase of a product, where the security team is assessing risks. In other organizations, security folks are brought in during the development phase, and in still others, not until the deployment. The bottom line: The more security is shifted left (e.g., into design), the smaller the risks and vulnerabilities down the road for customers and the company.
2. Rely on empowered development teams but include security specialists
One important component of empowerment is competence (others are control, clarity, and correction). Empowering the development team to take responsibility for the different security teams is a noble goal. However, it is essential to ensure that the development team knows what the security issues are, who on the team can be leveraged to add the knowledge, and what skills are needed. It’s also important to ensure the empowered team is effective enough to cover the necessary security aspects. Bringing in a security expert to the empowered development team is a great way to add value.
[ Want more DevSecOps strategies? See DevSecOps: 4 guiding principles for CIOs. ]
3. Implement features securely more than security features
Following this guideline is a tough but very effective tradeoff you should make. The desire for innovation within organizations must focus on embedding security within DevOps so that the result is a good software development process that achieves secure applications. While security features (e.g., authentication, access control) are essential, other topics, such as how to safeguard data from threats, are just as important.
4. Use tools as feedback for learning more than end-of-phase stage gates
Automation tools allow for improvements around tasks, processes, and decisions within the application lifecycle – for all stakeholders. However, one key aspect of automation tools is that they should be leveraged towards continuous improvement or feedback for learning. For example, continuous monitoring tools provide input into performance issues which should be shared with developers for feedback and optimization. Tools within continuous testing should provide input into improvements on test plans or test scenarios. Simply stated, learning is important as it improves individuals’ skills.
5. Build on culture change more than policy enforcement
Culture is difficult to define, and culture change is even more difficult to implement. While policy enforcements are one way to comply with security frameworks, it’s best to understand the organizational and security cultures before anything else as they often compete with each other.
Most importantly, remind humans that they are valued and necessary in the path to higher business security. These cultural shifts are especially important for organizations with remote, hybrid, or distributed teams.
[ How do containers and Kubernetes help manage risk? Read also: A layered approach to container and Kubernetes security. ]
