The disruptions caused by COVID-19 have become a huge opportunity to drive innovation and build a DevSecOps culture that emphasizes speed and agility while integrating security seamlessly throughout the software lifecycle. Not to mention, the acceleration of the Future of Work also revealed that nearly every department is now doing things that were never intended to be done from outside the data center. For example, customer billing needs to continue—despite the finance team working from home (at least for the near future). This likely has required pulling extremely sensitive data from a highly-secure database that is subject to strict compliance requirements. For engineering teams, remote code-reviews and architecture sessions are driving collaboration and exchange faster and further than we could have imagined.
The influx of digital and cloud transformation brought on by the pandemic also means that just about anyone can spin up a cloud instance with a single line of code or command. This new concept has forced business units to adapt quickly to customer needs, but left the organization open to all sorts of security risks. This change in operations has led to a clear need for an intuitive, scaled-down version of security frameworks that non-developers can use, which allows them to innovate quickly within boundaries defined by DevSecOps principles. Learning to cater to the non-developer is a trend that will take center stage as we continue to operate under business unusual.
Some Changes Will Likely Become Permanent
One change that is here to stay is the way we integrate security tools directly in the development platform. Traditionally, developers created code and then sent it to the security team to run through checks. Risks would be identified, but developers had little incentive to seek out feedback that was buried in a separate tool. With a DevSecOps approach, feeding real-time security notices and alerts alongside compiler warnings makes developers think about security throughout the process rather than as a check at the end. DevSecOps saves time, reduces errors, speeds time to market and eliminates much of the conflict that occurs between teams with seemingly disparate goals.
At Code42, we created a permanent new team within the security organization called Product and Application Lifecycle Security—PALS for short. A brainchild of some of our most trusted security experts, members of PALS have expertise up and down the stack—from networking and application access to compliance and architecture. They are embedded directly with our engineering team, participate in standups and help with scrum planning and execution. We’ve also set up a dedicated Slack channel and email alias where developers can get immediate feedback and input from the security team as they code. The result is that developers feel comfortable and confident when asking the security team for guidance remotely and at any time in the lifecycle as they develop our insider threat SaaS solutions. This has led us to a world of security at the speed of DevOps; our engineers have literally found pals in the PALS team who enable them to do their job faster, better and risk-free.
Avoid Blind Spots As You Settle Into New Ways Of Working
One thing that is getting overlooked is security. Opening up access to distributed users is introducing a whole new level of risk that organizations didn’t have to think about before. Software development platforms were never intended to live outside the firewall, but are being opened up to remote users in the name of business continuity. The market demands that products continue to evolve and code continues to be written—but at what cost?
Organizations need to rebuild development infrastructure and processes for the “new normal,” and there’s an opportunity to rethink software development with security in mind. The problem is that security has traditionally been seen as a roadblock to development agility. It has typically been separated from development, siloed with its own tools and processes. Code, perfect from the developer’s perspective, gets sent through the security ringer where it can be torn apart and watered down. Security checks on code add cost and complexity to efficient software development, increases tech debt and slows time to market. The perception is that when development says yes, security says no.
There’s an opportunity to change this dynamic in the time of COVID and moving forward. Rather than sit outside the development structure, security can be integrated directly into DevOps processes – implemented seamlessly throughout the software lifecycle at the speed developers, the market and users expect.
Setting Developer Team Goals For 2021
As you look into 2021 and you embrace innovation in your engineering practices, I still focus on the most important aspect of my process—agility. I measure our agility through several metrics and set specific goals for:
- Time to Developer Feedback: This is the time it takes for developers to get build feedback and test results when writing code. At Code42, we strive to keep this time under 15 minutes for simple pull requests, and less than an hour for full integration testing.
- Sprint Results: How did we do comparing the work planned to the work executed and what kind of delta did we have? We explore the reasons why we had variances and try to minimize them in the future.
- Test Control Coverage: In our DevSecOps world, you should think about test control coverage in two dimensions. First, it should provide the simple coverage we want as engineering leaders, and ideally, scale to full coverage in a microservices architecture environment. Second, your security control coverage should be aligned with the appropriate compliance framework.
- Engagement: This sounds squishy and admittedly, no one likes this, but an engaged team is an effective team. Polling teams and individuals for how they are feeling about their mission, purpose and values ensures they are with you through the journey and have a passion for success.
