This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Security Integration System"

From OWASP
Jump to: navigation, search
(Why: Problems the tool address)
(What is the Secure code assurance tool (SCAT))
 
(232 intermediate revisions by the same user not shown)
Line 2: Line 2:
  
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
+
| valign="top"  style="border-right: 1px dotted ;padding-right:25px;" |
  
== <b>Security integration system</b>==
+
==What is the Secure code assurance tool (SCAT)==
There are 3 domains to consider when securing software development.
+
<h1><b>What is the SCAT</b></h1>
<ol>
+
 
<li>The secure software development process</li>
+
[https://www.linkedin.com/pulse/secure-code-assurance-tool-scat-version-20-michael-bergman/ For more information on the <b>why</b> behind the SCAT, read my linkedIn Article here]
<li><b>Developing secure code</b></li>
 
<li>Continuous improvement</li>
 
</ol>
 
  
<br>
+
==What is the SCAT==
This OWASP project focuses on the <b>Developing secure code domain </b>and the <b>Secure code assurance tool</b>.<br>
 
<i>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.</i>
 
<br>
 
<br>
 
  
==<b>Description</b> ==
 
 
<ul>
 
<ul>
<li>Secure code assurance tool (SCAT) is a secure code assurance tool for both inhouse and third party development teams</li>
 
<li>SCAT is designed to be the “first line of defense” for the software development processes</li>
 
<li>SCAT is a simple 5 screen MVC, C# web application with a small footprint that can be deployed without further complicating development environment</li>
 
</ul>
 
  
== What: SCAT as First line of defense==
+
<li>SCAT is a <span style="text-decoration:underline;">process integrity tool</span>, implementing a consistent, authorized and auditable software development process
  
 +
<li>SCAT is used by development teams to build, verify and assure secure software
 
<ul>
 
<ul>
<li>SCAT is designed to be the “first line of defense” for the software development processes.  And performs the following functions</li>
+
<ol>
+
<li><strong>Build</strong>: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation
<li>Promoting compliance to security requirements</li>
+
<li>Minimising the impact of audit and assurance</li>
+
<li><strong>Verify</strong>: uses a combination of manual test plans and SATS tools to guide and verify correct implementation
<li>Informing risk based decision making</li>
+
<li>Integrating security into the software development process</li>  
+
<li><strong>Assure</strong>: centrally stores and publishes evidence of secure development and testing as an audit trail. Providing traceability through requirements and proving that security <span style="text-decoration:underline;">controls operate efficiently over a period of time</span>
</ol>
+
</li>  
 
</ul>
 
</ul>
  
== How: does the SCAT implement first line of defence==
+
<li>SCAT is <span style="text-decoration:underline;">not a point in time security verification tool </span>for detecting vulnerabilities after development</li>
 +
</ul>
  
<ol>
+
==Process integrity and point in time tools: How they work in the SDLC==
<li><b>Promoting compliance to security requirements</b>
 
[[File:Internal mapping.png|thumb]]
 
<ul>
 
    <li>Understand the security requirement: The tool maintains the following internal mapping allowing organisations to translate complex security requirements into code level and testing guidance</li>
 
        <ol>
 
            <li>Risks mapped to technologies and secure code requirements</li>
 
            <li>Secure code requirements (OWASP ASVS) mapped to secure code building block</li>
 
            <li>Secure test plans (OWASP testing guide) mapped to risks</li>
 
        </ol>
 
    <li>The second mapping is lifted from SKF and duplicated in the SCAT. I hope to link with the SKF and remove the duplicate functionality from the SCAT tool</li>
 
</ul>
 
</li>
 
  
 +
[[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]]
  
 +
<h1><b>Technical Description</b></h1>
  
<li><b>Minimising the impact of audit and assurance</b>
+
==Without further complicating development environment==
 
<ul>
 
<ul>
<li>In the testing and approval phase SCAT allows testers to stores testing evidence against the critical application function and its associated risk.  Providing traceability through requirements and centrally storing and publishing test evidence</li>
 
</ul>
 
</li>
 
  
 +
<li>SCAT is a simple 5 screen MVC, C# web application with a small footprint that can be deployed without further complicating development environment
 +
 +
<li>Integrates with Jira and runs ZAP and SonarQube in docker containers
  
 +
<li>SCAT is part of three domains to consider when securing software development.  <em>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.</em>
  
<li><b>Informing risk based decision making</b>
 
<ul>
 
<li>For each application critical function, SCAT shows</li>
 
<ol>
 
<li>The risks that impact that application critical function</li>
 
<li>Test plans to test that risk and how many test plans have test evidence</li>
 
<li>Security requirements to protect against the risk</li>
 
<li>How many security requirements have secure code blocks to guide implementation</li>
 
</ol>
 
<li>Allowing risk teams see levels of exposure, easily compare it to tolerance levels.  And prioritise and coordinate mitigation activities across teams and the whole application landscape</li>
 
</ul>
 
</li>
 
  
  
 +
<h1><b>See how developers use SCAT</b></h1>
 +
See below how the Secure code assurance tool integrates security into software development phases
  
<li><b>Integrating security into the software development process</b>
+
==Sprint planning phase ==
[[File:Integrate security.png|thumb|Integrate security]]
+
<b>Objective</b>: Ensures security requirements are understood <br>
<ul>
 
<li>SCAT wraps security theory, best practices and requirements into set of single purpose security screens. Then plots those screens against a specific SDLC phase</li>
 
<li>Plotting security screen to specific SDLC phases enhances development activities in those phases to include security</li>
 
<li>See below an example Secure software development procedure alongside short videos of how the SCAT tool integrates security</li>
 
</ul>
 
</li>
 
</ol>
 
  
== <b>Secure software development procedure using SCAT</b>==
 
See below how the Security code assurance tool integrates security into the phases of software development
 
<ul>
 
=== <li>Sprint planning phase</li> ===
 
 
     <ul>
 
     <ul>
         <li><b>Developers</b> use the <b>Identify risks</b> screen<br>
+
         <li><b>Developers</b> use the <b>Identify risks</b> screen to<br>
 
             <ol>
 
             <ol>
                 <li>To Select the application critical function they are developing/changing</li>
+
                 <li>Select the critical function to developing/changing</li>
                 <li>To identify the technologies they are using to develop/change the application critical function</li>
+
                 <li>Identify the technologies used</li>
                 <li>The Secure code assurance tools uses its internal mapping to automatically generate the security requirements associated with using this technology</li>
+
                 <li>Automatically generate the security requirements and tests</li>
                 [https://youtu.be/WQVzthyGL4U See how to use the tools and its internal mapping to generate security requirements]
+
                 [https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
 
             </ol>
 
             </ol>
         <li><b>Product owners</b> use the <b>Secure code requirements</b> screen<br>
+
         <li><b>Product owners</b> use the <b>Secure code requirements</b> screen to<br>
 
             <ol>
 
             <ol>
                 <li>To export security requirements for import into backlog management tools</li>
+
              <li>Create an audit trail to store evidence of secure development</li>
 +
                 <li>Create Jira tickets for requirements and tests to manage work</li>
 
             </ol>
 
             </ol>
 
       </li>
 
       </li>
 
     </ul>
 
     </ul>
  
=== <li>Development phase</li> ===
+
== Development phase ==
 +
 
 +
<b>Objective</b>: Ensure correct implementation of security requirements<br>
 
     <ul>
 
     <ul>
         <li><b>Developers</b> use the <b>Secure development</b> screen <br>
+
         <li><b>Developers</b> use the <b>Secure development</b> screen to<br>
 
             <ol>
 
             <ol>
                 <li>To see and understand how to attack and prevent the risks associated with the critical function</li>
+
                 <li>View and understand how to attack and prevent the risk</li>
                 <li>To see the secure code requirements to protect against exploitation</li>
+
                 <li>View the secure code requirements</li>
                 <li>To see the secure code block to guide developers to implement security requirements</li>
+
                 <li>View the secure code block to implement the security requirement</li>
                 <li>After development run a ZAP basic scan to verify security requirements have been correctly implemented </li>
+
                <li>Manage development effort in Jira</li>
                 [https://youtu.be/8J8KMaPnGOs See how the tool helps developers understand security requirements and write secure code]
+
                 <li>After development run a ZAP basic scan to verify security requirements have been correctly implemented</li>
 +
                 [https://youtu.be/1pSatE_7mEs See how the tool helps developers understand security requirements and write secure code]
 
             </ol>
 
             </ol>
 
       </li>
 
       </li>
 
   </ul>
 
   </ul>
  
=== <li>Testing phase</li> ===
+
== Secure code review phase ==
 +
 
 +
<b>Objective</b>: Ensure correct implementation of security requirements<br>
 +
 
 +
    <ul>
 +
        <li><b>Code reviewers</b> use the <b>Secure code review </b> screen to<br>
 +
            <ol>
 +
                <li>Guide manually secure code review</li>
 +
                <li>After manual secure code review run a Sonarqube scan to verify security requirements have been correctly implemented</li>
 +
                [https://youtu.be/ygre0SrWxD4 See how the tool verifies correct security requirements implementation]
 +
            </ol>
 +
      </li>
 +
    </ul>
 +
 
 +
== Testing phase==
 +
 
 +
<b>Objective</b>: Ensure valid security testing<br>
 
     <ul>
 
     <ul>
         <li><b>Testers</b> use the <b>Secure testing</b> screen<br>
+
         <li><b>Testers</b> use the <b>Secure testing</b> screen to<br>
 
             <ol>
 
             <ol>
                 <li>To see the OWASP test plans required to test the risk mitigation efforts</li>
+
                 <li>View the test plans required to test the risk</li>
                <li>To attach testing result to the test plan as control assurance evidence proving the risk has been mitigated</li>
+
                 <li>Manage testing effort in Jira</li>
                 <li>The Secure code assurance tool does not integrate with any testing tools other than OWASP ZAP.  Testing results generated outside of the secure code assurance tool is manually uploaded and stored</li>
+
                 [https://youtu.be/QdbCzheceUw See how the tool helps testers test risk mitigation efforts]
                 [https://youtu.be/VixapzUB_ts See how the tool helps testers test risk mitigation efforts and store testing evidence]
 
 
             </ol>
 
             </ol>
 
       </li>
 
       </li>
 
     </ul>
 
     </ul>
 +
== Approval phase ==
 +
 +
<b>Objective</b>: Streamline the approval and audit process<br>
  
=== <li>Approval phase</li> ===
 
 
<ul>
 
<ul>
         <li><b>Approvers</b> use the <b>Assurance evidence </b> screen<br>
+
         <li><b>Approvers</b> use the <b>Assurance evidence </b> screen to<br>
 
             <ol>
 
             <ol>
                 <li>To see relevant testing evidence alongside the risk, reducing the time assurance teams need to examine and approve releases</li>
+
                 <li>View relevant testing evidence alongside the risk, reducing the time assurance teams need to examine and approve releases</li>
                 <li>To see how many of the tests have test results</li>
+
                 <li>View verified development effort and whether it falls within risk tolerance levels</li>
                 [https://youtu.be/VixapzUB_ts See how the tool streamlines the approval process with centrally stored testing evidence]
+
                 [https://youtu.be/oyKK3Mq13B4 See how the tool streamlines the approval process with centrally stored testing evidence]
 
             </ol>
 
             </ol>
 
       </li>
 
       </li>
 
     </ul>
 
     </ul>
 +
== Risk management ==
 +
<b>Objective</b>: Enable risk managers to prioritise, plan and monitor mitigation efforts<br>
  
=== <li>Risk management</li> ===
 
 
     <ul>
 
     <ul>
         <li><b>Risk managers</b> use the <b>Application risk exposure</b> screen<br>
+
         <li><b>Risk managers</b> use the <b>Application risk exposure</b> screen to<br>
 
             <ol>
 
             <ol>
                 <li>To see each application critical function and the associated risks</li>
+
                 <li>View each application critical function and the associated risks</li>
                 <li>To see the number of <b>security requirements </b>for each risk, and which of those requirements have secure code block.  Allowing risk team to define where mitigation effort is required and monitors the progress of mitigation efforts</li>
+
                 <li>Identify where mitigation effort is required by viewing which risks require security requirements</li>
                 <li>To see the number of <b>security tests</b> for each risk.  Allowing risk team to determine where extra testing effort is required and monitor test coverage and quality</li>
+
                <li>Identify where development effort is required by viewing which security requirements need secure code blocks</li>
 +
                 <li>Identify where extra testing effort is required by viewing which risks require security test plans</li>
 
                 [https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
 
                 [https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
 
             </ol>
 
             </ol>
 
       </li>
 
       </li>
 
     </ul>
 
     </ul>
 +
<br>
 +
<br>
 +
 +
<h1> <b>Preparation phase</b></h1>
 +
When developing secure software we need to consider both standard secure code and client specific architectural requirements
  
== <b>Preparation phase</b>==
+
== Standard secure code requirements==
When developing secure software the SCAT helps development teams
 
<ol>
 
    <li>Write secure code </li>
 
    <li>Safely deploy in organisation environment </li>
 
</ol>
 
<br>
 
  
=== <b>Write secure code </b>===
 
 
<ul>
 
<ul>
    <li>There are security requirements that apply to all web applications e.g. code needs to protect against SQL injection</li>
+
        <li>SCAT comes out the box with a standard OWASP secure code requirements map. This mapping need to be modified to the specific organisation requirements</li>
    <li>The SCAT uses OWASP risks, security requirements and tests to guide development teams towards writing secure code</li>
+
<br>
    <li>The SCAT contains the OWASP data map out the box but it needs to be modified to fit the organisation</li>
+
         <li><b>Information security and development team</b> use the <b>Internal mapping </b> screen to
</ul>
 
<ul>
 
         <li><b>Information security and development team</b> use the <b>Internal mapping </b> screen<br>
 
 
             <ol>
 
             <ol>
                 <li>To map the security requirements to OWASP risks</li>
+
                 <li>Map the security requirements to OWASP risks</li>
                 <li>To map organisation approved secure code blocks to security requirements</li>
+
                 <li>Map organisation approved secure code blocks to security requirements</li>
                 <li>To map security test plans to OWASP risks</li>
+
                 <li>Map security test plans to OWASP risks</li>
                 [https://youtu.be/BXYk4oMue-M See how to setup the SCAT's internal mapping]
+
                 [https://youtu.be/EkWdAC1sbkE See how to setup the SCAT's internal mapping]
 
             </ol>
 
             </ol>
 
       </li>
 
       </li>
 
  </ul>
 
  </ul>
<br>
 
  
=== <b>Safely deploy in organisation environment </b>===
+
== Client specific architectural requirements==
 +
 
 
<ul>
 
<ul>
     <li>Organisations have environment specific security requirements, e.g. Log files in a format that can be consumed by SEIM, which DLP or authentication mechanism to use</li>
+
     <li>To generate these requirements we perform a risk assessment on client application landscape and identify</li>
    <li>The SCAT allows organisations to</li>
 
 
<ol>
 
<ol>
     <li>Create environment specific security requirements</li>
+
     <li>Critical applications and functions</li>
     <li>Import environment specific security requirements</li>
+
    <li>Risk associated with each critical application function</li>
 +
    <li>Architectural security requirements to secure each critical application functions</li>
 +
    <li>Client specific secure code blocks to implement security requirements</li>
 +
     <li>Secure test plans to verify risk has been mitigated</li>
 +
</ol>
 +
<br>
 +
    <li><b>Tool administrators</b> use the <b>Internal mapping </b> screen to
 +
<ol>
 +
    <li>Create json files of the organisation specific risks, security requirements, secure code blocks and tests</li>
 +
    <li>Import these into the SCAT</li>
 +
    [https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
 
</ol>
 
</ol>
 
</ul>
 
</ul>
  
==== <b>Create environment specific security requirements</b>====
+
<br>
 
+
<br>
<ol>
 
    <li>Identify the technical components used in client environment</li>
 
    <li> Identify the risks associated with using those technologies</li>
 
    <li>Define a set of security controls for each of the technologies</li>
 
    <li>InfoSec developers develop secure code blocks for each of the client specific secure code </li>
 
    <li>Create client specific SCAT - import data files</li>
 
</ol>
 
 
 
==== Import environment specific security requirements====
 
<ul>
 
        <li><b>Information security and development team</b> use the <b>Internal mapping </b> screen<br>
 
            <ol>
 
                <li>To Import and map environment specific security requirements to risks</li>
 
                <li>To Import and map environment specific secure code blocks to security requirements</li>
 
                <li>To Import and map environment specific security test plans to risks</li>
 
                [ See how the SCAT imports organisations environment specific security requirements]
 
            </ol>
 
      </li>
 
</ul>
 
  
== Who uses Secure code assurance tool (SCAT) ==
+
<h1>Project information</h1>
<ul>
 
<li>Information security, risk, assurance and compliance teams define strategic direction in security policies and requirements</li>
 
<li>Software development teams need to implement strategic direction in code. But don't always have time to study and understand huge security policy documents or complex requirements</li>
 
<li>SCAT is the integration layer between strategic direction and implementation and translates strategic security direction into code level and testing guidance </li>
 
<li>SCAT uses guidance, training, validation and integration to secure software and promote compliance, rather than costly post development policing</li>
 
</ul>
 
  
 
==Licensing==
 
==Licensing==
<span style="color:#ff0000">
+
This program is free software: you can redistribute it and/or modify it under the terms of the [http://www.gnu.org/licenses/agpl-3.0.html 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.
A project must be licensed under a community friendly or open source license.  For more information on OWASP recommended licenses, please see [https://www.owasp.org/index.php/OWASP_Licenses OWASP Licenses]. While OWASP does not promote any particular license over another, the vast majority of projects have chosen a Creative Commons license variant for documentation projects, or a GNU General Public License variant for tools and code projects.  This example assumes that you want to use the AGPL 3.0 license.
 
</span>
 
 
 
This program is free software: you can redistribute it and/or modify it under the terms of the [http://www.gnu.org/licenses/agpl-3.0.html 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. OWASP XXX and any contributions are Copyright &copy; by {the Project Leader(s) or OWASP} {Year(s)}. 
 
 
 
==Roadmap==
 
<span style="color:#ff0000">
 
As of <strong>November, 2013, the highest priorities for the next 6 months</strong> are:
 
<strong>
 
* Complete the first draft of the Tool Project Template
 
* Get other people to review the Tool Project Template and provide feedback
 
* Incorporate feedback into changes in the Tool Project Template
 
* Finalize the Tool Project template and have it reviewed to be promoted from an Incubator Project to a Lab Project
 
</strong>
 
 
 
Subsequent Releases will add
 
<strong>
 
* Internationalization Support
 
* Additional Unit Tests
 
* Automated Regression tests
 
</strong>
 
 
 
==Getting Involved==
 
<span style="color:#ff0000">
 
Involvement in the development and promotion of <strong>Tool Project Template</strong> is actively encouraged!
 
You do not have to be a security expert or a programmer to contribute.
 
Some of the ways you can help are as follows:
 
  
| valign="top"  style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
+
== Interested in contributing==
 +
[https://www.linkedin.com/in/michael-bergman-99826212a/ Please send a connect request with subject SCAT]
  
 
== Project Resources ==
 
== Project Resources ==
<span style="color:#ff0000">
 
This is where you can link to the key locations for project files, including setup programs, the source code repository, online documentation, a Wiki Home Page, threaded discussions about the project, and Issue Tracking system, etc.
 
</span>
 
  
[https://github.com/SamanthaGroves Installation Package]
+
[Installation Package]
  
[https://github.com/SamanthaGroves Source Code]
+
[Source Code]
 
 
[https://github.com/SamanthaGroves What's New (Revision History)]
 
 
 
[https://github.com/SamanthaGroves Documentation]
 
 
 
[https://github.com/SamanthaGroves Wiki Home Page]
 
 
 
[https://github.com/SamanthaGroves Issue Tracker]
 
 
 
[https://github.com/SamanthaGroves Slide Presentation]
 
 
 
[https://github.com/SamanthaGroves Video]
 
  
 
== Project Leader ==
 
== Project Leader ==
<span style="color:#ff0000">
+
[https://www.linkedin.com/in/michael-bergman-99826212a/ Michael Bergman LinkedIn]
A project leader is the individual who decides to lead the project throughout its lifecycle. The project leader is responsible for communicating the project’s progress to the OWASP Foundation, and he/she is ultimately responsible for the project’s deliverables. The project leader must provide OWASP with his/her real name and contact e-mail address for his/her project application to be accepted, as OWASP prides itself on the openness of its products, operations, and members.
 
</span>
 
 
 
[mailto://[email protected] Michael Bergman]
 
 
 
== Related Projects ==
 
<span style="color:#ff0000">
 
This is where you can link to other OWASP Projects that are similar to yours.
 
</span>
 
* [[OWASP_Code_Project_Template]]
 
* [[OWASP_Documentation_Project_Template]]
 
  
 
==Classifications==
 
==Classifications==

Latest revision as of 18:33, 14 October 2019

OWASP Project Header.jpg

What is the Secure code assurance tool (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

Process integrity VS point in time without check

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 below how the Secure code assurance tool integrates security into software development phases

Sprint planning phase

Objective: Ensures security requirements 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
    4.                See how to use the tools and its internal mapping to generate security requirements
      
  • 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

Development phase

Objective: Ensure correct implementation of security requirements

Secure code review phase

Objective: Ensure correct implementation of security requirements

Testing phase

Objective: Ensure valid security testing

Approval phase

Objective: Streamline the approval and audit process

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
    5.                See how the Application landscape overview screen informs risk based decision making
      



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
    4.                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
    3.     See how to import organisations specific risks, security requirements, secure code blocks and tests
      



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

Classifications

Project Type Files TOOL.jpg
Incubator Project
Owasp-defenders-small.png
Affero General Public License 3.0