Security as Code: Writing security requirements in Gherkin

Can a single file kickstart your DevSecOps loop? Putting the Sec in the DevOps is no easy task, especially in less structured projects. But application security has to be done, so we have to get creative about how to fit security practices inside the development process.

The following is an easy DevSecOps methodology to inject security requirements inside an application's repository in the form of a security.feature file, written in the Gherkin language. This way you can:

• update and version control SRs during development
• check if SRs are met during CI/CD or visually during code reviews.

A good framework to write security requirements to be consumed during development and/or testing is OWASP Application Security Verification Standard (ASVS).

This methodology also helps developers to keep a good posture according to the OWASP Software Assurance Maturity Model (SAMM), in particular with the Security Requirements and Requirements-driven Testing bits.

It's simple enough

Feature: Security Requirements

  # ASVS 2.1.1
  Rule: Verify that user set passwords are at least 12 characters in length.

    @Met
    Scenario: A user is registering
      Given the main registration form
      When a user fills the password field
      Then the validator should allow a minumum lenght of 12
  
    @Unmet
    Scenario: An administrator is creating a new guest user account
      Given the "New Guest User" form
      When a user fills the temporary password field
      Then the validator should allow a minumum lenght of 12

The methodology is straightforward:

• Write requirements as Rules (refering to ASVS as comments when possible)
• Provide at least an Example or Scenario for each requirement
• Tag Scenarios or the whole Rule with its current implementation status (e.g. Met, Unmet, UnderDevelopment) .

It is easier to use a single file with multiple Rules or Scenarios, but you can write multiple files with one Feature each as well (i.e. for different software components). Making use of the whole Gherkin syntax allows us to reproduce even complex applications behaviors.

Redact the security.feature file during design and then update it at each iteration and/or during code review and tests. The methodology is flexible enough to fit every software security maturity level or team composition.

Checking SRs status in CI/CD

A simple script involving the gherkin parser can read the feature file and list tags for each Scenario or even calculate the percentage of met SR compared to the total.

A one-liner to show tags in a simple feature file like the one above is the following, using jq:

gherkin security.feature --no-pickles --no-source | jq '.document.feature.children[] | .name,.tags[].name'

A note about Rule: gherkin-parser has issues recognising the keyword, since it has been introduced in v6. It is the most correct way to represent a SR, but if you plan to build a pipeline with a parser just comment it out.

Obviously if you already use Cucumber you can wire security.feature as a dummy test in your existing testing suite.