Security and the Twelve-Factor App - Step 9
A blog series by WhiteHat Security
July 15, 2019

Eric Sheridan
WhiteHat Security

In the previous chapter of this WhiteHat Security series, the Twelve-Factor App recommended scaling out via the process model discussed in Step VII, and included advice from the WhiteHat team on what to apply from a security point of view.

Step 9 of the Twelve-Factor App discusses disposability, which means that apps built using the twelve-factor methodology can be started or stopped at a moment's notice.

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
Start with Security and the Twelve-Factor App - Step 6
Start with Security and the Twelve-Factor App - Step 7
Start with Security and the Twelve-Factor App - Step 8

In the previous blog of this WhiteHat Security series, the Twelve-Factor App recommended scaling out via the process model discussed in Step 7, and included advice on what to apply from a security point of view.

Step 9 of the Twelve-Factor App discusses disposability, which means that apps built using the twelve-factor methodology can be started or stopped at a moment's notice.

Defining Disposability in the Twelve-Factor App

The ninth factor suggests maximizing robustness with fast startup and a graceful shutdown. This step focuses on getting code and app deployments quickly out of the starting blocks and functioning immediately. Likewise your application also needs to be strong against crashing, and if does crash, it needs to be able to restart cleanly.

The advantage with disposability in Twelve-Factor apps is that it supports fast elastic scaling, rapid deployment of code or configuration changes, and robustness of production deploys.

Applying Security to Step 9

An important factor to remember with disposability is to apply signatures and expirations to limit the life of derived security assertions. If for example the code is written without an expiration, and it's intercepted over the wire, that token can easily be re-used, something that you don't want to happen.

Eric Sheridan is Chief Scientist at WhiteHat Security
Share this