OWASP Scan IT

High Level Description

Scan IT is an application and source code manifest and associated tools to orchestrate and simplify important phases of the security scanning lifeCycle management of Applications.

The manifest: That describes important pieces of information that are normally required by most SAST and/or DAST tools to scan your code or application for potential vulnerabilities.

The Tools: To both facilitate the generation of the manifest and automate consumption and onboard of your apps into your commercial or open source scanning tools.


Problem Definition

You are now ready to roll out Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools in your enterprise! You secured the budget, bought the tool(s) and started onboard applications and/or code repos to be scanned by the tool X. For the first 5 apps, everything goes well but you quickly realize:

  1. This is an immense tasks - how do I scale for the next 20/30/100/200 apps

  2. We are losing too much time to customize & onboard the applications - each app has a “long time to market”. Which directories contain the test cases again ?

  3. Who owns this file/code/url ? You might have uncovered deeper fundamental problems in your organization code management approach as it relates to file/code ownership. Particularly when the bazaar approach is followed with no central control on code repository or source creation and maintenance.

  4. How do I test specific features ? Are there any ares of the application that should be off limits ?

  5. Which users can I use to login in the test environment ?

SAST and DAST are a great way to find security defects in code or applications at scale. Experience tells us that getting the most value from these important programs can be tricky. We need a new approach to extract the most value for our investment.


Proposed Solution

Enter the scan_it.yaml file: A structured approach to describe the relevent properties of a code repository to SAST/DAST/IAST Tools.

 As a development team, you will create and maintain a “scan_it” file in your code repo (think about it as CODEOWNERS on steroids).
 
 As a centralized security organization, you will now be able to parse scan_it files and automatically use your sast/dast provider APIs to automatically onboard/update the setup of applications to your tools.
 
 As a tool vendor, you will be able to support your customers in the challenging mission of onboarding applications into your products. Better time to market for your customers, higher customer satisfaction.

In a nutshell

  • It allows developers to enjoy the flexibility of no central repository creation workflows
  • It allows security teams to track code repository ownership, phase, contact info, folder exclusions, etc. For simplified SAST tools automations and management
  • It minimizes de time for project onboarding and notification of code scanner findings
  • Given limited AppSec engineer time and budget, it helps reducing risk by making the overall process more efficient

High Level Workflow


The Format

The file (“scan_it.yaml”) is a YAML configuration file that will contain the necessary specification and configuration to facilitate your application consumption by both the security team and/or the security automation tools. In this document, we intend to cover:

  1. Why YAML

  2. The Configuration File

  3. Reference

  4. Examples

By the end of this document, we are hoping you can easily understand and create the simple but useful scan_it file for your application. Below a sample scan_it.yaml file:

 
version: 0.1
about:
 generic:
  name: "super_uber_app"
  id: 123456
 stack:
  languages:
   - "python:3.7"
   - "pl/sql"

source:
 type: "git"
 repo: "https://github.com/OWASP/www-project-scan-it"
 repo_user: $SVC_USER_NAME 
 repo_pwd: $SVC_PWD #never add your creds here, just a placeholder
 paths:
  - 
   path: '*'
   ignore: 
    - '*.xml'
    - '*.dll'
    - 'test*.py'
    - '/src/test'
   contact:
    - email: team_manager@company_example.com
   ticket:
    type: 
     - email
     - jira

  - 
   path: '/src/apps'
   ignore: this_file.py
  
  - 
   path: '/src/apps/super_awesomeCode/bpmEdit.py'
   contact:
      - email: amazing_dev@company_example.com
 

Why YAML

YAML (YAML Ain’t Markup Language) is a user friendly syntax for writing software configuration and specifications. There is a lot of internet content over the pros and cons on the most widespread configuration file formats such as XML, JSON and YAML. Some of the main reasons why we selected the YAML file for this project are:

  • YAML is user friendly - easy to read and understand by humans

  • Very widespread and good programming language support.

  • Support for comments - which is not valid in JSON