OWASP Security Integration System

![OWASP_Project_Header.jpg](OWASP_Project_Header.jpg "OWASP_Project_Header.jpg")

What is the SCAT

For more information on the why behind the SCAT, read my linkedIn Article here

What is the SCAT

  • SCAT is a process integrity tool, implementing a consistent, authorized and auditable software development process
  • SCAT is used by development teams to build, verify and assure secure software
    • Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation
    • Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation
    • Assure: centrally stores and publishes evidence of secure development and testing as an audit trail. Providing traceability through requirements and proving that security controls operate efficiently over a period of time
  • SCAT is not a point in time security verification tool for detecting vulnerabilities after development

Process integrity and point in time tools: How they work in the SDLC


Technical Description

Without further complicating development environment

  • SCAT is a simple 5 screen MVC, C# web application with a small footprint that can be deployed without further complicating development environment
  • Integrates with Jira and runs ZAP and SonarQube in docker containers
  • SCAT is part of three domains to consider when securing software development. I've detailed the other domains in an article that will be published in the Nov/Dec issue of the ISC2 magazine, I will add a link here after publication.

    See how developers use SCAT

    See below how the Secure code assurance tool integrates security into software development phases

    Sprint planning phase

    Objective: Ensures security requirements are understood

  • Product owners use the Secure code requirements screen to

    1. Create an audit trail to store evidence of secure development
    2. Create Jira tickets for requirements and tests to manage work
  • </ul>

    Development phase

    Objective: Ensure correct implementation of security requirements

    </ol> </li> </ul>

    Secure code review phase

    Objective: Ensure correct implementation of security requirements

    </ol> </li> </ul>

    Testing phase

    Objective: Ensure valid security testing

    </ol> </li> </ul>

    Approval phase

    Objective: Streamline the approval and audit process

    </ol> </li> </ul>

    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

    </ol> </li> </ul>

    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 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

  • </ul>

    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

    </ol> </ul>

    Project information


    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

    </td> </tr> </tbody> </table> [Category:OWASP Project](Category:OWASP_Project ) [Category:OWASP_Builders](Category:OWASP_Builders ) [Category:OWASP_Defenders](Category:OWASP_Defenders ) [Category:OWASP_Tool](Category:OWASP_Tool )

  • Example

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