Security and the Twelve-Factor App - Step 1
A blog series by WhiteHat Security
June 07, 2018

Eric Sheridan
WhiteHat Security

The Twelve-Factor App is a methodology that offers a 12-step best practice approach for developers to apply when building software-as-a-service apps that are both scalable and maintainable in a DevOps world. As software continues to be written and deployed at a faster rate and in the cloud, development teams are finding there is more room for failure and vulnerabilities. This blog series will discuss how to build a Twelve-Factor app securely.

This first blog in the series looks at Step I, Codebase, in more detail.

Defining Codebase in the Twelve-Factor App

According to 12factor.net, a Twelve-Factor app is always tracked in a version control system, for example Git, Mercurial or Subversion. A copy of the revision tracking database is referred to as a "code repository," which developers often shorten to "code repo" or simply "repo."

A "codebase" is therefore any single repo, or set of repos, that share a common root, in a decentralized revision control system. The Twelve-Factor advocates putting all code into one repository or source control system that is tracked in revision control. So essentially there is only one codebase per app, but there can be many deploys of the app.

Applying Security to Codebase

Having one codebase tracked in revision control, with many deploys is the ideal, but it’s important to remember that your code is only as secure as the systems used to build it. As the guardian of the code and the systems in which it is housed, what steps can you as a developer take to ensure that the repository is properly secure?

1. Lock it down

These days source code is the core of most businesses, therefore it’s imperative to protect it. The best way to do this is by imposing restrictions — limit access to the source code repository to authenticated users only. Believe it or not it’s very common for people to be able to view the entire source code when on the internal network. While this maintains integrity, unfortunately it can put your entire intelligent property at risk.

Limit commits to pull requests as opposed to direct commits. This refers to a source management system model, in which no one can write directly to the source code repository. Pull requests are reviewed by the team responsible for the master code, which then decide whether to merge the new code with the existing base, or not. In this way the codebase is protected through the provision of checks and balances. Ultimately, limiting commits is an enabling requirement that acts as a shield for other activities.

2. No more secrets

Write code as if everything you did was open sourced. To share a practical example of this, there’s a scene in the movie Sneakers (1992) where Robert Redford’s character realizes that "Setec Astronomy," the name of the project that produced a black box, was actually an anagram for "Too Many Secrets." Soon after, Redford’s engineers realized that the black box was actually a piece of hardware capable of decrypting anything and everything — to which Redford then famously (at least for me) said "No More Secrets." In the same way we need to apply the idea of "No More Secrets" to our code. It means developers should write application code with the assumption that it could be disclosed, so ideally the goal will be to have no secrets in the actual application.


Externalize secrets and make their location known via startup arguments. This means putting secrets into configuration files where people can find them. Use the environment to protect the configuration.

3. Review code regularly

Enforce secure coding guidelines via a review of all pull requests. Throughout the software development stage, there are only a few key inflection points i.e. central areas where everything merges, where changes can be made. It’s a good policy to use these central points to enforce your company’s security guidelines. From a coding point of view these guidelines can include:

a. Use organizationally approved cryptographic controls.

b. Make use of HTTP security headers for all responses.

c. Consistent use of contextual encoding via HTML templating engines.

d. All database queries are performed using variable binding.

e. Keeping your dependencies updated.

Successful development teams find it’s equally important is to educate the team regarding solutions to pull requests that fail code reviews. It’s key to understand why some pull requests are rejected, and how the team can work to avoid these issues.

Teamwork

Collaborating in terms of sharing feedback will go a long way towards promoting awareness, and ultimately supporting the coding of applications that can be done more quickly, efficiently and securely. It’s an approach that should in fact be applied to all 12 steps of Twelve Factor.

Read Security and the Twelve-Factor App - Step 2

Eric Sheridan is Chief Scientist at WhiteHat Security
Share this

Industry News

December 06, 2022

The Cloud Native Computing Foundation® (CNCF®), which builds sustainable ecosystems for cloud native software, announced the graduation of Argo, which will join other graduated projects such as Kubernetes, Prometheus, and Envoy.

December 06, 2022

Wib announced API PenTesting-as-a-Service (PTaaS) designed to help organizations proactively cover the latest PCI-DSS 4.0 mandates for testing application security, APIs, and vulnerabilities in Business Logic.

December 05, 2022

Harness announced Harness Cluster Orchestrator to allow customers to optimize their Kubernetes cloud workload costs and realize up to 90% cloud cost savings with Amazon Elastic Compute Cloud (Amazon EC2) Spot instances from Amazon Web Services (AWS).

December 01, 2022

Salesforce introduced a new Automation Everywhere Bundle to accelerate end-to-end workflow orchestration, automate across any system, and embed data and AI-driven workflows anywhere.

December 01, 2022

Weaveworks announced that Flux, the original GitOps project, has graduated in the Cloud Native Computing Foundation (CNCF®).

December 01, 2022

Tigera announced enhancements to its cluster mesh capabilities for managing multi-cluster environments with Calico.

December 01, 2022

CloudBees achieved the Amazon Web Service (AWS) Service Ready Program for Amazon Elastic Compute Cloud (Amazon EC2) Spot Instances.

November 30, 2022

GitLab announced the limited availability of GitLab Dedicated, a new way to use GitLab - as a single-tenant software as a service (SaaS) solution.

November 30, 2022

Red Hat announced an expansion of its open solutions publicly available in AWS Marketplace.

November 30, 2022

Sisense announced the availability of the Sisense CI/CD Git integration module.

November 29, 2022

Codenotary announced TrueSBOM for Serverless, a self-updating Software Bill of Materials (SBOM) for applications running on AWS Lamda, Google Cloud Functions and Microsoft Azure Functions that is made possible by simply adding one line to the application source code.

November 29, 2022

Code Intelligence announced its open-source Command-Line Interface (CLI) tool, CI Fuzz CLI, now allows Java developers to easily incorporate fuzz testing into their existing JUnit setup in order to find functional bugs and security vulnerabilities at scale.

November 29, 2022

Parasoft announced the 2022.2 release of Parasoft C/C++test with support for MISRA C:2012 Amendment 3 and a draft version of MISRA C++ 202x.

November 28, 2022

Kasm Technologies announced the release of Kasm Workspaces v1.12, providing major enhancements to its portfolio of digital workspaces delivering Desktop as a Service (DaaS), Virtualized Desktop Infrastructure (VDI), Remote Browser Isolation (RBI), Open-Source Intelligence Collection (OSINT), Training/Sandboxes, and Containerized Application Streaming (CAS).

November 28, 2022

Cloud4C has achieved Amazon Web Services (AWS) DevOps Competency status.