Editor's note: This guest post was contributed by Snyk.
Is continuous security possible? If it is, what does that mean for your team and your software development lifecycle?
Continuous security?
Development teams have seen enormous benefits from implementing continuous integration (CI) and continuous delivery (CD) as well as continuous deployment practices. By setting up a CI/CD pipeline, teams can merge small changes often, release code to production frequently and feel confident doing so because any changes trigger a build that is tested automatically before being released. This workflow means that development can move forward at a relatively steady pace compared to other methodologies. Additional benefits of CI/CD practices include increased confidence that the shipped code has been properly vetted--build and delivery failures are noticed faster and if a rollback is required, it usually affects a small piece of functionality rather than a major release.
When changes are continuously integrated and quickly delivered to production, security needs to be continuous as well. If security is not addressed in a similar manner, one of two possible scenarios play out: Either security is addressed but becomes a bottleneck, ruining the forward momentum of the project; or security concerns fall to the wayside because addressing security issues would interrupt the workflow. Neither of these is an option; so let’s consider continuous security.
Shift left
In a traditional software development lifecycle, security concerns are usually addressed towards the end of the process. By the end of the process, code has been written and tested, while the security team needs to complete their review before the code is merged and released. In this scenario, security considerations can easily cause delays.
However, if we start thinking about security early in the software development lifecycle, we can address concerns in a more incremental and manageable way. This is sometimes called “shifting left”, as we are moving security to earlier in the process (or left, as we read from left to right).
Consider the time and development effort that can be saved by catching a vulnerability soon after it is included—when it is comparably easier to address without a major refactor.
On the other hand, when security is addressed only prior to deployment and a vulnerability is found, an engineer needs to debug the build and potentially work parts of the project over again from scratch—this could be a critical time loss in a competitive market. Consider too that this time savings could be the difference between deciding to address a security issue or putting it off to be fixed at a later date. If security vulnerabilities are addressed early, this can save your team time and frustration upfront, and could also save you from a costly incident down the line.
By adopting the following practices, you can move your project towards a continuous security posture.
Consider security early and often. The earlier you catch a vulnerability, the easier it is to make changes. Think incrementally. Security is something that can be considered with every pull request. By breaking it up and thinking about it every time, you make it more manageable. Automate wherever you can. The best way to ensure compliance with a security policy is to automate!
Let’s see how CloudBees CodeShip and Snyk can help you with this process.
Snyk + CloudBees CodeShip
CloudBees CodeShip integrates with the development tools that you use for source control, deployment, and more to set up your CI/CD pipeline more easily. Snyk is a security tool used to help you find and fix security vulnerabilities in your open source dependencies. Snyk integrates seamlessly with CI/CD pipelines that were built with CloudBees CodeShip.
Snyk checks for vulnerabilities in your dependencies throughout the software development lifecycle. Snyk CLI tools help developers make better dependency choices while they are writing code. Additionally, checks can be set up to run before code is merged and before code is released to production. You can choose whether vulnerabilities fail a build or simply give a warning, and these settings can be tailored based on the severity of the vulnerabilities found.
New security vulnerabilities are found all the time. Just because your project had no known open source dependency vulnerabilities when it was released does not mean that there are no known vulnerabilities today. Snyk informs you when a new vulnerability is discovered in any of the packages that you are using. We also have a tool that monitors your code in production and lets you know when there is a vulnerable function within your open source dependencies--making it easy to prioritize and address issues as they occur.
Join us
Are you interested in adding continuous security to your CI/CD pipeline? Want to learn more about the benefits of addressing security issues throughout the software design lifecycle? Please join us for an upcoming webinar on May 16 at 1pm ET, Continuous Integration, Continuous Delivery. Continuous Security? We will demonstrate how, with CodeShip and Snyk, you can address security throughout the CI/CD pipeline. We hope to see you there!
Additional resources
Learn more about CloudBees CodeShip security specifications
Read about how to deliver secure apps on Kubernetes
Listen to the podcast about DevSecOps