Shifting to an Integrated Security Approach
By- November 22, 2019
At Tinfoil, we’re going to spend this month taking time to care about one of the most important things - you! That’s right, this month is our month of empowering customers so they’re successful. We’ll be writing some blog posts and posting some videos to help make your security for DevOps implementation easier. If you have any questions you want answered about anything security or SecDevOps related (or kitten related, because we like those, too!), email email@example.com.
Our first post is a question we see a lot:
I get a lot of push back from developers on having to worry about security. They produce a lot of our security bugs. How can I fix this?
This is a great question! Security isn’t easy, otherwise everybody would be secure. To implement security across your development teams, you need to identify the root of the problem. Do your developers feel held back from building? Does it feel like there’s so much added process that it blocks development? Is there a barrier of intimidation to be tackled to really empower your developers? We’ve seen each of these cases, but understanding what’s happening in your organization makes all the difference.
The most common objection we hear from developers stems from one fact: security is hard… really hard! Oftentimes, this difficulty intimidates engineers. Perhaps there’s a fear of job security, or maybe the tools you’re providing your developers are too difficult to understand. Fear is most easily assuaged by good education. Turn security into a fun competition and you’ll often see developers come out of their shells, challenging themselves and you. See how your current security tools can integrate into the development process, be simplified, and be more easily understood. Do your tools provide a 97-page PDF? That’s probably not going to work for your development teams.
Sometimes, developers will push back on implementing security because it takes too much time. If the new process you’ve given your development team is blocking your engineers from creating something new, it’s best to add security as a process without making your developers ever _feel_ like there’s a new process. Hooking into your CI system so vulnerabilities are found with the existing testing process lets security get tested with all of their existing unit, regression, and integration tests. Inserting a vulnerability into their issue tracker as a normal bug allows your developers to start looking at it in the same place as all of their other features and bugs. Bonus points if your security tools provide remediation instructions for each vulnerability! Security will naturally become less intimidating, and your developers will learn to consistently produce more secure code.
The least common objection we see is complacency: “security doesn’t matter to me.” This is mostly an educational gap that needs to be worked through. In this rare case, understanding your team dynamic and what drives each team lead and member is crucial. Sometimes, gamifying security piques the team’s interests. Sometimes, the drive to learn, paired with educational classes on how vulnerabilities on the development team have been built in the past can help. Bonus and reward structures might help a more stubborn team.
Shifting from a traditional cybersecurity approach to an integrated security approach is tough. It takes management buy-in and a lot of hard work, but it pays off in the long run. You know your team better than we do, and each team can be pushed in many different ways, and we’re happy to help. Let us know how we can!
This post is from our month of empowering customers for success series. Have a question you want answered about anything security or SecDevOps related (or kitten related, because we like those, too!)? Email firstname.lastname@example.org.