Manuel D'Orso

This is a DevSecOps methodology to write down security requirements for an application 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.

Example

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 simple: – 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 the implementation status (Met, Unmet, UnderDevelopment etc)

It is easier to use a single file with multiple Rules or Scanarios, but you can write multiple files with one Feature each as well (i.e. for different software components).

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

Checking SR status during 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.