What is the Path to Self-Securing Software?

As digital business hastens the speed of application development and gives way to complex, interconnected software systems (think Internet of Things, microservices and APIs), we need to address that penetration testing, although thorough, is slow and expensive. On average, it takes eight months to identify and understand the cyber and regulatory risks associated with any new software, according to research from security company Sonatype.

Software development trends are compounding the issue in that software is being built and released faster (see the “Agile Manifesto”), but the tools and people resources to address security risk are not keeping pace.

Trends such as DevOps that require security teams to deliver deep integration and the automation of security tooling drove us, in conjunction with Centre for Secure Information Technologies at Queen’s University Belfast, to ask the question, “What is the path to self-securing software?”

Penetration testers and tools will only scan the website they can observe; there could be many aspects missing from the testing scope. However, what is really interesting is that in reality, the CODE contains everything that the website can do (functionality, data, etc.).

We were interested to discover if there a way to scan code to automatically understand WHAT it is. For example, is it a website or desktop application? Does it allow the user to enter financial info or personal details? If it does, where is that info stored? This information can be used to drive other testing tools or penetration testing by informing them of what the code is, the associated functionality, data types, etc. In essence, this information can automatically inform the scope and focus of security testing.

We looked at source code parsing technology, and how, by using it, we can determine what a web application actually is/does. Antlr was deemed to be a popular tool in this area, allowing us to build a tool that scanned website source code and provided us with a digital understanding of the website. We could then use that data to drive automated security tools.

The result? We were able automatically understand the attack surface of a website by scanning the code. We could then use that intelligence to further drive manual, commercial or other open source testing, facilitating continuous, and automated, security testing of developing code. Since the orchestration and execution of security testing was automated, it could easily be wrapped into development teams’ daily (or weekly) processes, flagging security issues long before the system was deployed externally.

We believe that the tool we created (and have further developed at Uleska) is addressing the “pressing need to orchestrate tools and automate testing in a continuous delivery pipeline and facilitate AST at scale, as well as improve context and prioritization for remediation efforts” that Gartner has identified for so-called ASTO (Application Security Testing Orchestration) tools that are coming onto the market.

[ISACA Now Blog]

Source: https://www.isaca.org/Knowledge-Center/Blog/Lists/Posts/Post.aspx?ID=1067