Much like George R. R. Martins’s vision of the infamous Nights Watch in Game of Thrones, we continue to hunt for ways we can keep you safe.
This year, we want to give you a peek at how we uphold our fundamental security principles – an insight into some of the practices and techniques we have within our company. We are proud of our security stance and have several projects happening over the next twelve months, continuing to re-affirm the positive security position we hold.
What is Shift-left?
The term “shift-left” has recently become a bit of a buzzword, especially in the Security and DevOps circles.
If we think about a traditional software development lifecycle (SDLC), especially the waterfall model (diagram 1), it shows the testing phase towards the right-hand side. Here, compiled products are handed over (or thrown over the fence) to the testing teams. Any changes due to bugs or requirements mean the development process must be reset, creating potential time delays.
Shift-left is a practice intended to bring testing forward, so it occurs much earlier within the development lifecycle. This move has led to the waterfall model being replaced by other, more tightly coupled processes, such as Agile in the test development world. This same idea is now becoming more popular in the Security and DevOps industries, where security functions are also being integrated much earlier in the software development processes:
In the above diagram, security impacts are within consideration from the beginning of a project (Stage 1), with security specialists involved in the requirements and the design processes. This approach carries on throughout each stage, right into post-launch, where monitoring and maintenance of the production system are with a security stance.
Why is Shift-left important for developing security?
Most of the benefits of shift-left security are akin to the testing industry:
- Software defects are found earlier in the process. A defect found in the early stages of the development process is much cheaper and quicker to fix – this is the same for any security issues.
- Earlier feedback – this is not just bugs. Earlier input on the UX/UI means empowering developers and testers to make significant changes happen earlier. Even security issues can have an impact on the user experience.
- Tight communication loop between stakeholders and testers – meaning changes are much more rapid, and people feel more entrusted to make changes as problems present themselves.
- Customer satisfaction is significant for any business. Buggy software leads to unhappy customers.
- Security/compliance reporting – if a security issue shows itself in a live environment, it has the potential to affect actual customer data. And this could be a costly process with GDPR and other regulations, where any data breach needs reporting.
Key points for success with shift-left testing
Here are some key points that will help implement shift-left into your security strategy.
1. Secure frameworks
For security to be tightly integrated, companies need a secure development lifecycle. Secure development lifecycle frameworks outline the necessary procedures required at each development stage. This structure helps identify issues early in the software development process and reduces vulnerabilities in a production system (diagram 2).
2. Threat modeling
Before the implementation has happened, Threat Modeling is a crucial stage and can take many forms, depending on the organization structure. Threat modeling gets the key stakeholders (developers, test engineers, etc.) to review the system design, focus on security, uncover potential threats, or identify test tasks needed to verify the system is secure. Whether using Adam Shostack’s Elevation of Privilege Game or an online threat modeling tool, the core process aims to get people together, talking about security.
3. Automation
Automation is an essential tool to help save time and reduce the repeatable jobs that need completing for each project. This principle applies to all areas. Continuous Integration, for example, is a great way to take some of the manual work required. Having developers regularly merge their code changes into a central repository allows automated builds, automated testing, and specifically automated security checks to be performed frequently. Repeatability helps to reduce the chance of human errors, and having results logs means it can reference for future testing.
A great example of an easy-win is integrating security tests and OWASP Top 10 payloads into automated tests. This technique means minor changes to the software tests, and you can identify security flaws through existing testing frameworks.
4. Using tools
There are many tools available to help with the implementation and testing stages of the SDLC. Static Application System Testing (SAST) tools search through source code to identify known poor coding patterns, which could cause security issues. Developer feedback loops also become more effective by checking for insecure functions and harmful practices as the code is checked in.
Dynamic Application Security Testing (DAST) can assist with hands-on testing and analyze the software as it runs, hoping to find bugs that we cannot identify purely from the source code. In a similar vein, Software Composition Analysis (SCA) tools can be used directly on the code repositories or as part of the build pipeline to identify security risks. These threats reveal compliance violations through out-of-date packages/dependencies, such as using dependencies with a strict non-commercial usage license.
5. Organizational changes
An overarching need to make “shift-left security” work is a culture change – to get buy-in from all stakeholders involved. If security is an item on the agenda from the top-down, budgets can allow the purchasing of tools and time allocated to security-focused tasks. Communicating security throughout is vital. For example, ensuring developers have training in the right area and using demos or lightning talks. It can help knowledge share to provide best practices that are widely known.
Conclusion
Shift-left testing has been embedded into the software development processes at RealVNC for many years. Our development team has included software testers for over fifteen years, and that team has grown and developed dramatically over that time. Dedicated testing environments allow testers to work on projects in parallel. Working with the security team allows these to not be a blocker in the development process but instead reduce turnaround time and aim to get releases into production more efficiently.
You now have an idea of some of the security best practices RealVNC has been following. We have several security initiatives happening this year to continue strengthening our internal processes, and we’ll be able to share more on this later in the year.
