Time pressure opens several areas of vulnerabilities in organizations’ software development lifecycle security.

Imagine this: you are the CISO of your company and, just days from launching a new mobile app, you find a vulnerability in the app that potentially spells disaster. Would you launch the application, hoping that no hackers will discover it?

Many organizations may think they have a solid application security strategy in place but, in actual fact, more than half of them consciously deploy vulnerable applications due to time pressures, according to an ESG study.

CybersecAsia caught up with Ian Hall, Asia Pacific Client Services Manager at Synopsys Software Integrity Group, who is speaking on this topic at the Black Hat Asia 2020 conference.

In your opinion, why would an organization push out an application knowing that it has vulnerabilities?

Ian: There are various reasons why an organization may choose to push an application to production with known vulnerabilities but the most common reason is probably to meet a critical deadline – the vulnerabilities may have been found too late in the development lifecycle to be able to address it while still meeting the deadline. This is backed up by the data in a recent study done by the Enterprise Strategy Group (ESG).

Is there any situation in which it would be worth the risks?

Ian: An organization will need to perform their own assessment of a specific vulnerability for their application in their organization since circumstances can be very different even for the same vulnerability. A good starting point is the CVSS base score but that may change based on the application itself which may not contain and Personally Identifiable Information (PII) and hence have a lower risk rating for the organization. 

What an organization can do is to take into account the various factors such as the data that is at risk in the application, severity of the vulnerability, exploitability of the vulnerability and finally whether there are other mitigations in place already – for example a web application firewall would add protection against some vulnerabilities found in a web application.

In the recent BSIMM11 report, it finds that many security responsibilities are now being led by engineering teams rather than security teams.  CI/CD instrumentation is becoming a standard components of organisations’ software security initiatives. As the development speeds in these organisations increase, there’s also a shift to “good enough” in terms of security rather than “zero risk”.

What are the possible consequences and how should businesses go about addressing them?

Ian: There are three different areas that I would suggest organizations look to prevent known vulnerabilities moving to production:

1. SDLC integration – Security testing should be done whenever possible in the software development lifecycle as well as via automation. In the past talk would be about “shifting left” but now the recommendation is to “shift everywhere” meaning that security activities should be performed as soon as the artifacts to be reviewed are available.
   
2. Best practice guidelines for developers – In most cases, developers are not security experts so they need sufficient guidance to develop secure code.
   
3. Managing open source – A lot of focus in security testing is often on the code written by your own developers, however the majority of modern codebases are actually made up using Open Source Software (OSS). It is critical to understand what OSS is being used and what vulnerabilities are being introduced to your code via that OSS.

What are some key areas in application security that organizations handle poorly? How should they be avoided?

Ian: I will be discussing this topic in detail on October 1^st at Black Hat Asia, however I would say that two common themes are around the management of OSS and education of developers. 

On the OSS front, ensuring that an organization has an accurate Bill of Materials (BOM) of the OSS components being used is a critical starting point and following on from that ensuring that vulnerabilities from these components are addressed and that the components themselves are kept up-to-date will protect the organizations.

Educating developers on how to fix vulnerabilities is not just about providing training but it is also about helping them to prioritize defects, providing actionable remediation advice as well as monitoring the metrics to track the efficacy of training that has been provided. There are IDE plugins available on the market that were designed to enable developers in this way.