Security is an essential and critical part of any product development process. Due to the continually shifting nature of security, it should be high on every business's agenda. It seems almost every day in the media we’re reading about a new vulnerability found within a piece of software that was previously thought to be secure, or a new data breach coming from a large company.
A common approach to security with code is to push it far down the pipeline to the Information Security (InfoSec) team, where they would test the application for any security issues and compliance. As can be seen in the diagram below, such testing can require hours and hours of input from Developers and Testers through to DevOps Engineers and the InfoSec team itself.
- A Developer takes a week to write a snippet of code
- They deploy the code to the staging server via the pipelines where the code gets tested
- Once completely approved and tested, the code is then sent to a demo server where testers review the code again
- The code is about to be released
- Hold on! InfoSec takes a look, and it’s bad news. The underlying open source component, which your code relies on, is insecure and cannot be used
- The Developer has to rewrite their code and begins Step 1 again
Not only is this process time-consuming, but because it requires much effort, it impacts team morale. Because of this, Delio decided to take a different approach: shifting the security check ‘to the left’ during development.
Boosting morale with a more efficient security check approach
Security checking ‘to the left’ is essentially the process of moving these checks to the start of the development cycle. It reviews whether code is secure from the get-go rather than waiting until the end, where the risk of securely rewriting large amounts of code is high.
It all starts with the right tools. We use several tools to help us check whether the code appears to be correct (using static code analysis) and check our open source dependencies for vulnerabilities against a database of Common Vulnerabilities and Exposures (CVE). This whole process by design is integrated into our CI* pipelines. On each push to our source code control repository, the pipeline can be checked alongside our tests. By adapting our pipeline, we have been able to make deployments more efficient.
Placing security checking & compliance ‘to the left’ comes with its speed penalties. However, you can easily overcome such penalties by running multiple pipelines in tandem. At Delio, for example, we now run our tests, our static code analysis and our open source vulnerability tool all at the same time. It’s also quicker to fix issues as they present, rather than much later down the pipeline when the developer has moved onto other work and then has to ‘task switch’ back to the original work.
The benefits
For us, here at Delio, it means we’re saving precious development time. Also, more importantly, we’re instilling secure development practices from the start of the work, which is recommended as nobody wants to ship insecure code. Besides making the team manage workflow more efficiently, it is helping Developers understand security from the get-go. The team is being upskilled and more aware of the impact their code can have in terms of security. As a result, we’re shipping new features quicker and more securely to our clients’ platforms.
With all of these pipelines running our tools and processes, you significantly diminish the chances of running vulnerable code in production. Nobody can ever be 100% positive whether a piece of code is vulnerable or not, but that is why strengthening the security process while making it more time-efficient, is a continuous operation.
Where next?
The next part of the puzzle is having your pipelines set correctly, as it can help shorten your security analysis. Robust CI/CD* pipelines mean that an Open-Source Dependencies Check can be more easily integrated into the pipeline. Just remember to block the pipeline if your security scan fails. For example, here at Delio, we block it until we have fixed any vulnerabilities, so no further code is added until it passes all pipeline automated tests.
Despite all of this, wouldn’t it be even better if we could review the code security in real-time? This process is one of the things we are currently reviewing. Adding these tools directly into the Integrated Development Environment (IDE), allows Developers to check for security while writing their code in real-time. Whether there is a problem with the written code or whether one of the open-source dependencies is on the CVE database, these instabilities can be flagged instantly. In doing so, Developers can save a considerable amount of back-and-forth checking. By turning security into a continuous process, businesses can drive their technology to the next level.
*CI/CD: Continuous Integration/Continuous Deployment. This pipeline automates the development, testing and deployment of code.
