The previous chapter in this WhiteHat Security series highlighted the individual build, release and run stages within the app-building process, and the appropriate security posture to incorporate within each of these phases.
Start with Security and the Twelve-Factor App - Step 1
Start with Security and the Twelve-Factor App - Step 2
Start with Security and the Twelve-Factor App - Step 3
Start with Security and the Twelve-Factor App - Step 4
Start with Security and the Twelve-Factor App - Step 5
Step 6 of the Twelve-Factor App methodology encourages executing the app as one or more stateless processes. Here is some actionable security-focused advice which developers and ops engineers can follow during the SaaS build and operations stages.
Defining Processes in the Twelve-Factor App
In this sixth step, the Twelve-Factor methodology encourages executing the app as one or more stateless processes by using small programs that communicate over the network. In other words Twelve-factor processes are stateless and contained in a shared-nothing (SN) architecture, a distributed-computing architecture in which each node is independent and self-sufficient, and there is no single point of contention across the system. More specifically, none of the nodes share memory or disk storage. The benefits of SN architecture include eliminating any single point of failure, allowing self-healing capabilities. and providing an advantage in offering non-disruptive upgrade.
Many organizations are undertaking a “re-platforming” journey, in which the overarching platform is broken up into smaller programs that are more service focused, enabling changes to be made more quickly.
Applying Security to Step 6
Unfortunately, a major security drawback of this journey is that when you start to break up a big building block into smaller pieces, the attack surface increases. This means there are more places where requests can be sent to your infrastructure, which equates to more opportunities to send an attack. Assumptions about how code would be invoked by their callers will change when migrating to service oriented architectures, and some of those changes impact security. By way of example, consider the WhiteHat Security 2018 Stats Report. This report compared vulnerability related security metrics between monolith and microservices architectures and found that for every 100KLOC, monolith applications had 39 vulnerabilities whereas microservices had 180 vulnerabilities. Be mindful of legacy code that is being exposed over the network as you break up your app into services, as such code may have been written without security in mind.
In the next chapter, Step 7 will be covered, which focuses on exporting services via port binding, and what to apply from a security point of view.
