Edwin Kwan, Head of Application and Software Security at Tyro Payments
Software development has evolved from a waterfall development model to an agile model. Development cycles have shrunk from releasing new versions a few times a year to every couple of weeks or in some organisations, multiple times a day. The applications themselves have also reduced in size, having gone from being large monolithic systems to micro services and now even serverless. And ownership of the applications has also changed. We’re moving from a model where applications were once built by developers and then managed by operations, to a “You Build it, You Run it” DevOps model where the team who builds the application is responsible for its operation. Development teams that were once made up of only software engineers are now cross-functional teams and have quality/testing and operations expertise.
The application security landscape has also changed over time. It started as black-box security penetration testing, where the assessors had no knowledge of the application's inner workings This has evolved into white-box testing with the assessor having access to the application’s source code. This has improved the quality of their testing as assessors can refer to the source code to determine if a vulnerability exists. We’ve also seen the introduction of vulnerability scanners and automated security scanning tools. Some of those tools include Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Software Composition Analysis (SCA). SAST does source code analysis to find security vulnerabilities. DAST scans the running application to detect conditions that indicate a security vulnerability. SCA scans the third party, often open-sourced components used by the application for known vulnerabilities.
Penetration testing is still an activity that is performed towards the end of the software development life cycle. However, vulnerability and automated security scanning tools have allowed application security testing to be done earlier. Organisations have shifted security to the left, doing security earlier in the development life cycle, and adopted a continuous application security testing model. This is done by embedding application security testing into the build phase of the software development life cycle, particularly into the Continuous Integration (CI) pipelines. While this approach is a significant improvement to how organisations do application security testing, the approach can be further improved through supply chain management and addressing technical debt in open source components.
As the bulk of modern applications are created using open source components, doing due diligence during the open-source selection process and dealing with stale dependencies will address many potential security vulnerabilities
As modern applications become more dependent on open source components, one of the biggest challenges we're facing is stale dependencies. Stale dependencies are when an application's open-source components become outdated and are not getting the bug or security fixes that have been addressed by their newer versions. Keeping open source components up to date is not a trivial task as new versions are occasionally not backward compatible. They can introduce breaking changes, and there is potentially a substantial economic cost associated with it. However, as open-source components make up a significant portion of an application's code, usually, most of the security vulnerabilities reside. Letting dependencies become stale and only addressing them once a security vulnerability has been detected is disruptive and slows development significantly. While open source components allow applications to be developed quickly, the associated maintenance effort required is often neglected. This is commonly referred to as the open-source "tax". What organisations need to be doing is scheduling work to address this "tax" on a regular basis. A best practice approach is to mandate that applications must not have stale dependencies when released. Besides, time must be set aside to address stale dependencies in the other applications which are not actively being developed. The benefit of reducing stale dependencies is the reduction in the number of future security vulnerabilities and the time required to address them.
As the bulk of modern applications are created using open source components, doing due diligence during the open-source selection process and dealing with stale dependencies will address many potential security vulnerabilities. These additional controls, coupled with other vulnerability scanners, automated security scanning tools, and penetration testing, will help to speed up development, create more secure applications and reduce business risks. The future of application security is to shift further left.