Breaking News

Microservices Security

It Gets Worse Before it Gets Better

For every 100KLOC, a monolithic application will have an average of 39 vulnerabilities, whereas a microservice application will have an average of 180 vulnerabilities. You read that right. According to the data gathered from WhiteHat Security’s 2018 Application Security Statistics Report (WhiteHat 2018 Stats Report), the transition of enterprise monolithic applications to distributed microservices architectures is actually increasing the overall average of total vulnerabilities. But why? Why is it that we seemingly continue to make the same mistakes again and again? And what does this say about the security of microservices architectures, or the developers that build them?

The journey to a microservices architecture generally involves the decomposition of an already existing monolith application, wherein previous security assumptions and considerations are often questioned and sometimes invalidated.

Data aggregated for the WhiteHat 2018 Stats Report was obtained from 100K+ security scans across 20K+ applications yielding 1M+ verified vulnerabilities. Within this data, we carved out those applications that constitute a microservice and compared their security scan data against that of traditional monolithic applications. We were initially surprised to see that microservice applications had vastly more vulnerabilities per 100KLOC than monolithic applications, 180 and 39 respectively. In our attempt to better understand this statistic, we dug deeper into the vulnerability data, focusing on common classes of vulnerability as well as those deemed to be critical.

We found that WhiteHat Sentinel most frequently identified the use of vulnerable third-party components. Using WhiteHat Security’s Software Composition Analysis (SCA) capability, we were able to catalog those components used to develop microservices as well as identify those containing known exploitable vulnerabilities. Imagine you are responsible for maintaining a monolithic application that declares and makes use of a vulnerable third-party component. This component is declared once, and thus, is represented as a single (1) vulnerability in Sentinel.

Now imagine that you are decomposing that same application into 25 separate microservices. Assuming those microservices continue to leverage the same third-party component (ex: a JSON parsing component), then you now have 25 vulnerabilities represented in Sentinel as opposed to one!

We see at least two key takeaways from this trend: 1) vulnerable third-party components will continue to be one of the most common vulnerability classes for years to come and 2) the ability to identify the use of a vulnerable third-party component across an entire application portfolio is critical to organization-wide remediation efforts.

In our review of specific vulnerabilities with customers, it became clear that a number of vulnerabilities stem from the delta in attack surface between monolithic and microservice applications. This delta often challenged and, in some cases, invalidated previously held security assumptions about how code was consumed. Consider the following anonymized NodeJS (JavaScript) code snippet. See anything wrong?

module.exports = async(req, res) {

  let message = req.body;

  let id = message.id;

 

  let entities = await sequelize.query(

    `SELECT * FROM Entity WHERE ID = ${id}`,

    { type: sequelize.QueryTypes.SELECT }

  );

 

  // TODO: do something with “entities”

 

  res.send(202);

}

Code Snippet: NodeJS App Leveraging Sequelize ORM

This is a classic SQL Injection vulnerability, whereby the “id” field of a structured object submitted in the request body (JSON in our customer’s example) was used to build and evaluate dynamic SQL code. This code was originally used in a monolithic application in such a way that the “id” value was deemed to be retrieved from a trusted source, whether it was a properties file or a static literal.

As a part of the decomposition from a monolith to a microservice, this vulnerable piece of code was exposed via a REST-like API. A hacker that is able to directly or indirectly submit a request to this microservice could carry out a potentially devastating SQL injection attack. The term “technical debt” is commonly used amongst software engineers to denote those decisions where a short cut was taken in such a way that the cost, or effort to do it correctly, will eventually have to be paid at a later date. This NodeJS scenario is just one such example of technical debt specific to security that we found when digging further into our vulnerability data.

There is, however, a silver lining here. The WhiteHat 2018 Stats Report shows that developers of microservice applications are able to remediate vulnerabilities at a faster pace than their monolithic counterparts. The average remediation rate for a microservice is 54% compared to monoliths at 47%. More encouraging, the average time to fix a vulnerability is 43 days for a microservice compared to 95 days for a monolith. This data helps further validate one of the key value propositions of microservice architectures – the ability for development teams to more quickly respond to issues. This is encouraging in that it demonstrates once you are able to get past the initial security pains from transitioning to microservices, you and your team will be able to respond faster to vulnerabilities discovered in your code. Until then, consider time to pay the (Pied) Piper.

 

Tags: microservices, Vulnerabilities, vulnerability