If we were to ask, “what are some of the modern practices that we should be doing in our software development?”, the more obvious frameworks that would come to mind are Agile and DevOps. They are an alternative to traditional project and operational management. They help teams respond better to rapidly changing business needs through small, incremental work cadence with a tight feedback loop.
DevOps is not a new concept; practically all industries are adopting it now. Here at WhiteHat Security, we understand that development teams are under constant pressure to release products and features faster every day. Many of them have implemented what’s considered the “next-gen” of DevOps – Continuous Integration and Continuous Delivery (CI/CD). This is focused on releasing often and automating as much as humanly possible. In a typical waterfall environment, you may release once every few months. In a CI/CD environment, it’s common to push code to production several times per week, or even several times per day. In extreme CI/CD, we see software builds every few minutes or seconds.
To do this, developers use several development and deployment tools, such as Eclipse, Jenkins, Maven, Ansible, Chef or Puppet, and are able to make continuous releases into production. However, with such adherence to the principles of velocity and agility, security is frequently an afterthought, at best.
Security is Not the Enemy (we promise)
Releasing software as quickly as possible puts pressure on developers to just write and release code without checking to see if that code is secure. The need for speed can cause problems throughout the entire SDLC, especially if that code or product has already been “shipped” to the marketplace.
Imagine if you were able to identify security issues early in the process – specifically at the beginning of the SDLC. You could eliminate chronic migraines for multiple teams, from development through audit and operations, and (of course) IT Security, but it would especially save the developer from having to shoulder the blame of creating insecure code. Why not expand the developers’ autonomy by giving them technology that scans their code for vulnerabilities before it’s shared with peers or the world?
WhiteHat Scout™ does just that. It is a fully automated static analysis testing product that is designed for developers. It is personal to them and allows them to scan their code, as they are writing it and fits seamlessly into their CI/CD workflow using tools they are already using for their development such as Eclipse, Maven, Jenkins etc.
This is what DevSecOps is all about. It’s about removing walls (including security) that impede the flow of applications that drive modern digital enterprises. Injecting security into the process early reduces errors and means that vulnerabilities can be resolved faster. It also reduces the costs and resources associated with fixing security flaws, by building security into every stage of the development process, from the requirement stage onwards ultimately helping enterprises to innovate securely at speed and scale.
Why not get in there early and prevent these potential problems?
Everyone Has a Role in Security
In our view, developers DO, in fact, care about security, but often lack the training necessary to write secure code. Developers will not begin writing secure code just because their boss says so. Maybe they don’t have the knowledge and resources to accomplish this task.
If security shifts further left in the SDLC, closer to developers, they can scan their code as they write it, obtain fast and accurate feedback on security flaws in their freshly written code, and fix them, before a domino effect from those vulnerabilities affects the business.