Q1. Andreas, how has the growing adoption of serverless computing, hybrid cloud, microservices, containerization, and other trends complicated the application security testing challenge for enterprise organizations?
There are three key trends that are impacting application development and changing the way we test applications for security:
First, applications used to (and many still do) run behind a corporate firewall, which provides basic security protection. As they move to cloud or mobile platforms, this protection goes away, and the attack surface shifts directly to the application. Similarly, embedded software used to run on stand-alone, unconnected devices, precluding remote intrusions by an attacker. Now devices are increasingly networked, making them and their embedded software applications vulnerable to cyberattacks. As a result, the applications themselves have become the focal point of cyber-protection and need to be hardened for security, including their functional code, interfaces, and interactions with other software components (and possibly also hardware).
Second, the speed of application development has dramatically increased, driven by business needs and facilitated by agile development processes, CI/CD flow automation, and DevOps support. In response, AppSec testing tools must support fast turnaround times, fit into an automated, staged CI/CD flow, and provide comprehensive reporting to support quick deployment decisions. Moreover, higher release agility shifts the responsibility to address security issues to the developers. To minimally impact productivity, AppSec testing tools must be highly accurate, with a low false-positive rate, and offer actionable remediation advice.
Third, application architectures are shifting away from monolithic executables and are now built as a set of microservices, allowing a LEGO-style composition of higher-level functions from lower-level building blocks that communicate over web APIs. Most importantly, they support a flexible and scalable operational architecture based on containers and automated deployment orchestration to public/private clouds or a hybrid combination of them. As a result, the cyberattack surface has significantly broadened due to the increased numbers of APIs and the expanded scope involving many services, potentially running across multiple compute platforms. For this reason, AppSec tools, including SAST, DAST, SCA, and IAST, must be container, microservices, cloud infrastructure, and network aware. Furthermore, comprehensive API security testing has become a critical element of an overall AppSec testing strategy.
Q2. Steve, from a capabilities standpoint, what does it take to manage the risk posed by the use of open source software in modern application development?
First and foremost, you need to know what's in your code. You obviously can't patch something you don't know you have, but open source is hard to keep track of. Whether a developer pulls in a piece of code they used in a prior-generation product or downloads something from a website, it's up to the development organization to maintain an accurate and up-to-date inventory of all open source components in use within the applications their company deploys. In short, you first need to know what is in your product.
Armed with this visibility, the development organization then needs to be able to enforce open source policies during development so that problematic open source can be flagged and addressed early in the SDLC. The challenge here is matching this governance with the increasing speed of development. So it's critical that any enforcement methodology can be automated and integrated with the CI/CD and DevOps tools and processes the development teams are using.
Finally, and perhaps most importantly, once software is in production, it's imperative to be able to quickly and reliably determine when newly reported vulnerabilities affect the software, so that patches can be deployed before hackers have the opportunity to exploit them. This is why building an accurate inventory ahead of time is key. As an example, the Apache Struts issue was a result of this visibility gap. Had the affected organization known what open source was in their code, they could have easily found and fixed the problem before hackers compromised their customer data.
Q3. Andreas, what are some of the key attributes that organizations should be looking for when shopping for an IAST product, and why?
Many are hailing interactive application security testing (IAST) as the next step in the evolution of application security testing. Gartner expects IAST adoption to have exceeded 30% by 2019 as it provides significant advantages over other testing methodologies.
No matter which IAST solution an organization chooses, there are a few key features you should look for:
- Fast, accurate, and comprehensive results out of the box, with a low false-positive rate: Development and QA teams need to focus on quickly finding critical security vulnerabilities and must avoid wasting time on debugging false positives or tuning tools to reduce them.
- Automated identification and verification of vulnerabilities: Advanced IAST tools automatically verify the validity of complex vulnerabilities, further reducing or even completely eliminating false positives.
- Detailed security guidance and remediation advice: To maintain their productivity, developers need detailed and contextual information about vulnerabilities, where they are located in the source code, and how to remediate them.
- Comprehensive support for microservices: For complete coverage of modern application architectures, an IAST solution must be able to easily cross multiple microservices from a single application for assessment.
- Ease of deployment in automated CI/CD workflows: Seamless integration into multistage CI/CD pipelines is critical for quickly establishing development environments, especially for organizations that have to support a large number of projects.
- Updated security dashboards for standards compliance: An IAST solution must support reporting on security standards such as PCI DSS, OWASP Top 10, and CWE/SANS Top 25 to provide organizations insight into security risks, trends, and coverage, as well as security compliance for operating web applications.
- Sensitive data tracking: To achieve compliance with key industry security standards such as PCI DSS and GDPR, advanced IAST products support tracking of sensitive data in applications.
- SCA binary analysis capability: Teams need visibility into security vulnerabilities and license types in open source and third-party components used in an application. Advanced IAST tools support binary analysis to identify these components and alert teams of known security vulnerabilities or license violations.
Q4. Steve, which of Synopsys' announcements and developments over the past year would you highlight at Black Hat USA 2019? What can attendees at the event expect to hear about the company's plans for the next few years?
In February 2019, Synopsys announced the first release of the new Polaris Software Integrity Platform, which is aimed at integrating the components of our product portfolio into an easy-to-use solution that enables security and development teams to build secure, high-quality software faster.
The vision of the Polaris platform was inspired by our customers. They asked us to integrate our various point solutions into a single platform that simplifies installation, usage, and maintenance; supports cloud, on-premises, and hybrid deployments; and are in tune with modern development workflows. When architecting Polaris, we had three key stakeholders in mind:
- The developer and the security engineer want a single UI and a unified workflow to understand vulnerability findings and remediation advice from different tools, and a unified method to triage the results.
- The security manager, CISO, or other executive wants a single-pane-of-glass view to assess the security posture of their application portfolio, with consolidated results from their various testing tools.
- The DevOps engineer wants a unified method to install, upgrade, and maintain the platform and deploy it in a scalable manner.
The Polaris platform is composed of two main components. The Polaris Code Sight IDE plugin serves as a developer workbench, running the tools locally in an incremental mode. This helps developers address many security issues as they code, essentially preventing issues from getting checked into the code repository in the first place. The Polaris Central Server is integrated into the central CI/CD workflow and ensures that any remaining defects are caught before the application goes to production.
Going forward, we will continuously expand the capabilities of Polaris using this strategy by adding more technology and services components, broadening support of workflow integrations, and improving individual tool capabilities. In particular, we are exploring how our different core technologies can supplement one another, making their combination significantly more powerful than the sum of the individual pieces.