Note: This is the second installment in a blog series on startup security in a DevOps world (read the first here). This series is an adaptation of an e-book published in 2017, which was originally contributed to by JumpCloud CEO Rajat Bhargava and guest contributors Alan Shimel and Ben Tomhave. Read their bios below.
When working with technology, startups need to think about security concerns — both initially, when planning infrastructure and choosing solutions, and on an ongoing basis to proactively secure their applications and environment.
Because startups move quickly and need to remain agile, we recommend they work ongoing security into their existing workflows and cycles and look for security enablers and accelerators within their current tools and environment. The DevOps approach is one of the best ways to accomplish this, as it facilitates fast implementation, quick changes, and better success rates. This blog will discuss ways to approach ongoing security for applications, patch management, logging and monitoring, and incident management with a DevOps mindset.
The DevOps approach poses significant advantages for application development, deployment, and ongoing improvement, from more frequent code deployments to fewer failed change implementations and less outage-induced downtime. With this in mind, it’s important to take a DevOps approach with application security as well as development and deployment. Start by incorporating these three key lessons from DevOps that make application security more important and tangible to development teams:
1. You break it, you fix it!
In keeping with the culture of DevOps, resolution of security issues should be owned by the developers, not by security personnel. It’s one thing to allow a security expert to follow-up and ensure timely remediation, but culturally, it’s important that developers realize they own the responsibility.
2. Fail fast, learn faster!
Shortening feedback cycles is a critical element of DevOps, and this includes security. Application security testing (AST) should occur as early in the process as possible and feedback should be delivered directly to developers so as to more readily own and resolve any issues.