Shipping your application fast is such a vital step. So is shipping a secure and bug-free application. You want to show your customers that there are new features added to your product. You also fix bugs so that your customers are not facing those issues again and again.
Development methodologies are all implemented with one thing in mind: “Deliver value fast”. But when you are shipping so fast, many times, vulnerabilities make it to production.
Why you should focus on finding security issues early
Everyone wants to find security vulnerabilities in the code during the development process. If a vulnerability makes it to production, it is a matter of time before it’s exploited by some hacker. This article will give you a great insight about vulnerability and security.
According to NIST (National Institute of Standards and Technologies), the cost of fixing vulnerabilities on production is 60 times more than during development. So, you can understand that fixing a vulnerability during development is much better than fixing it after it hits production.
Also, there are some mistakes which cannot be undone. What if you have pushed a mobile application build which has a secret inside it? That release is gone, and hence there is a possibility that the key can be reverse engineered. Then the only option left for you will be to make a new release and revoke the old key.So the questions that come to mind are – What can we do to detect such vulnerabilities at the development stage itself?What tools are available which can help us during the development and the testing phases?
Tools to help you during the development cycle
There are a lot of tools and technologies available to help us find vulnerabilities during development and testing.
Vulnerabilities need not be only security loopholes. They can be logical errors as well which can get exploited. For example, in this article, we can see how to detect memory leaks using the available tools.
There are tools available to scan code for secrets. For example, GitHub scans code for such keys. Even AWS labs have tools which we can use inside our Git hooks or CI Pipelines. Gitlab also provides pipelines which you can use to perform such actions. Here’s an article on how you can use CI with Gitlab for Laravel.
Then there are tools available for checking the OWASP top 10 vulnerabilities. It is a list compiled based on vulnerabilities across many sites and applications. This list is available on the OWASP website. Users can go through this and safeguard their applications from such known issues.
All these are done with only one thing in mind – the more you are able to automate things, you invest some time doing that. And then, you continue to reap benefits from the time that you invested on it.
I have been a part of setting up git hooks and code formatters etc. You can see this article on how to set husky for some automated stuff during git commits. But, somehow things do get missed on developer’s environments. The idea is to have these things baked into your pipelines. This way, they never interfere with the development flow. Rather, the developer doesn’t need to do anything extra for all these good things to happen.
Plus, when you configure your pipelines in a generic way, they are easy to improve. For example, our pipelines are quite similar for a Node and a Laravel application. And, now to introduce a security scan stage is quite easy across multiple Any new rule set or test which gets flagged as important by the security team. So, implementing them across pipelines is quite easy. Compare that to finding ways to implement on different projects using different technologies.
Using a strong CI pipeline can help us focus more on doing development. Some common problems will get caught during the development phase. Having said that, pipelines can only detect things which fit within their rules. Code reviews and developer’s understanding of security best practices is a must. I would like to know what you think about CI and its role in solving these issues.