OWASP Riyadh

SCAT
  • Table of content
    1. What is the SCAT process integrity tool and how does it work
    2. See how development teams use the SCAT process integrity tool
    3. Customising the SCAT process integrity tool to your development environment.
    4. For more information on the why behind the SCAT, read my linkedIn Article here.

    What is the SCAT process integrity tool and how does it work

    What

  • Writing secure code is only one of the five esential security components that comprise a "Secure Software development process.
  • The five esential security components of a "Secure Software development process are:
    1. Security governance: Consistant and predictable output, where teams know what to do and when it must be done.
    2. IT risk management: Defined criticality and priority.
    3. Security requirements: In proportion to criticality.
    4. Writing secure code: Correctly and completely implementing the security requirements.
    5. Assurance: Evidence of correct and complete implemention.
  • SCAT functions as a process integrity tool to overlay the SDLC and implement these esential security components.

    • How

  • SCAT process integrity tool enforces a Secure software development process and enables development teams to build, verify and assure secure software.
    1. Build: Integrates a combination of code level guidance and on demand training to define the security requirments before development begins and guide software developers towards its correct implementation.
    2. Verify: Integrates point in time security verification tools to verify that the security requirments are met.
    3. Assure: Integrates an audit trail to centrally store evidence of secure development and testing. Providing traceability through requirements and proving that security requirements were implemented correctly and will operate efficiently over a period of time.
    SCAT Process integrity VS point in time vulnerabilty scanning tools

    See how development teams use the SCAT process integrity tool

    Sprint planning phase

    Objective: Generate security requirements before development begins and ensure they are understood
  • Developers use the Identify risks screen to
    1. Select the critical function to developing/changing
    2. Identify the technologies used
    3. Automatically generate the security requirements and tests
  • Product owners use the Secure code requirements screen to
    1. Create an audit trail, where the development team will stores evidence proving that the security requirements were met.
    2. Create Jira tickets assigning the security requirements and its accompaning evidence collection tasks to the development teams.
    See how to use the tools and its internal mapping to generate security requirements </td> </tr>

    • Development phase

    Objective: Ensure correct implementation of security requirements
  • Developers use the Secure development screen to
    1. View and understand how to attack and prevent the risk
    2. View the secure code requirements
    3. View the secure code block to implement the security requirement
    4. Manage development effort in Jira
    5. After development run a ZAP basic scan to verify security requirements have been correctly implemented

    See how the tool helps developers understand security requirements and write secure code

    		•

    Secure code review phase

    Objective: Ensure correct implementation of security requirements
  • Code reviewers use the Secure code review screen to
    1. Guide manually secure code review
    2. After manual secure code review run a Sonarqube scan to verify security requirements have been correctly implemented

    See how the tool verifies correct security requirements implementation

    		•

    Testing phase

    Objective: Ensure valid security testing

  • Testers use the Secure testing screen to
    1. View the test plans required to test the risk
    2. Manage testing effort in Jira

    See how the tool helps testers test risk mitigation efforts

    		•

    Approval phase

    Objective: Streamline the approval and audit process
  • Approvers use the Assurance evidence screen to
    1. View relevant testing evidence alongside the risk, reducing the time assurance teams need to examine and approve releases
    2. View verified development effort and whether it falls within risk tolerance levels

    See how the tool streamlines the approval process with centrally stored testing evidence

    		•

    Risk management

    Objective: Enable risk managers to prioritise, plan and monitor mitigation efforts

  • Risk managers use the Application risk exposure screen to
    1. View each application critical function and the associated risks
    2. Identify where mitigation effort is required by viewing which risks require security requirements
    3. Identify where development effort is required by viewing which security requirements need secure code blocks
    4. Identify where extra testing effort is required by viewing which risks require security test plans

    See how the Application landscape overview screen informs risk based decision making

    		•

    Preparation phase

    When developing secure software we need to consider both standard secure code and client specific architectural requirements

    Standard secure code requirements

  • SCAT comes out the box with a standard OWASP secure code requirements map. This mapping need to be modified to the specific organisation requirements
  • Information security and development team</b> use the Internal mapping screen to
    1. Map the security requirements to OWASP risks
    2. Map organisation approved secure code blocks to security requirements
    3. Map security test plans to OWASP risks

    See how to setup the SCAT's internal mapping

    Client specific architectural requirements

  • To generate these requirements we perform a risk assessment on client application landscape and identify
    1. Critical applications and functions
    2. Risk associated with each critical application function
    3. Architectural security requirements to secure each critical application functions
    4. Client specific secure code blocks to implement security requirements
    5. Secure test plans to verify risk has been mitigated

  • Tool administrators use the Internal mapping screen to
    1. Create json files of the organisation specific risks, security requirements, secure code blocks and tests
    2. Import these into the SCAT

    See how to import organisations specific risks, security requirements, secure code blocks and tests

    Project information

    Licensing

    This program is free software: you can redistribute it and/or modify it under the terms of the link GNU Affero General Public License 3.0 as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

    Interested in contributing

    Please send a connect request with subject SCAT

    Project Resources

    [Installation Package]

    [Source Code]

    Project Leader

    Michael Bergman LinkedIn

    Example

    Put whatever you like here: news, screenshots, features, supporters, or remove this file and don’t use tabs at all.

    Watch Star