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"
MB netblue4 (talk | contribs) (→Secure software development procedure using SCAT) |
MB netblue4 (talk | contribs) (→Description) |
||
Line 29: | Line 29: | ||
<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> | <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> | </ul> | ||
+ | |||
+ | |||
+ | == <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> | ||
+ | <li><b>Developers</b> use the <b>Identify risks</b> screen<br> | ||
+ | <ol> | ||
+ | <li>To Select the application critical function they are developing/changing</li> | ||
+ | <li>To identify the technologies they are using to develop/change the application critical function</li> | ||
+ | <li>The Secure code assurance tools uses its internal mapping to automatically generate the security requirements associated with using this technology</li> | ||
+ | [https://youtu.be/WQVzthyGL4U See how to use the tools and its internal mapping to generate security requirements] | ||
+ | </ol> | ||
+ | <li><b>Product owners</b> use the <b>Secure code requirements</b> screen<br> | ||
+ | <ol> | ||
+ | <li>To export security requirements for import into backlog management tools</li> | ||
+ | </ol> | ||
+ | </li> | ||
+ | </ul> | ||
+ | |||
+ | === <li>Development phase</li> === | ||
+ | <ul> | ||
+ | <li><b>Developers</b> use the <b>Secure development</b> screen <br> | ||
+ | <ol> | ||
+ | <li>To see and understand how to attack and prevent the risks associated with the critical function</li> | ||
+ | <li>To see the secure code requirements to protect against exploitation</li> | ||
+ | <li>To see the secure code block to guide developers to implement security requirements</li> | ||
+ | <li>After development run a ZAP basic scan to verify security requirements have been correctly implemented </li> | ||
+ | [https://youtu.be/8J8KMaPnGOs See how the tool helps developers understand security requirements and write secure code] | ||
+ | </ol> | ||
+ | </li> | ||
+ | </ul> | ||
+ | |||
+ | === <li>Testing phase</li> === | ||
+ | <ul> | ||
+ | <li><b>Testers</b> use the <b>Secure testing</b> screen<br> | ||
+ | <ol> | ||
+ | <li>To see the OWASP test plans required to test the risk mitigation efforts</li> | ||
+ | <li>To attach testing result to the test plan as control assurance evidence proving the risk has been mitigated</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/VixapzUB_ts See how the tool helps testers test risk mitigation efforts and store testing evidence] | ||
+ | </ol> | ||
+ | </li> | ||
+ | </ul> | ||
+ | |||
+ | === <li>Approval phase</li> === | ||
+ | <ul> | ||
+ | <li><b>Approvers</b> use the <b>Assurance evidence </b> screen<br> | ||
+ | <ol> | ||
+ | <li>To see 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> | ||
+ | [https://youtu.be/VixapzUB_ts See how the tool streamlines the approval process with centrally stored testing evidence] | ||
+ | </ol> | ||
+ | </li> | ||
+ | </ul> | ||
+ | |||
+ | === <li>Risk management</li> === | ||
+ | <ul> | ||
+ | <li><b>Risk managers</b> use the <b>Application risk exposure</b> screen<br> | ||
+ | <ol> | ||
+ | <li>To see 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>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> | ||
+ | [https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making] | ||
+ | </ol> | ||
+ | </li> | ||
+ | </ul> | ||
== How: does the SCAT implement first line of defence== | == How: does the SCAT implement first line of defence== |
Revision as of 16:45, 26 August 2019
Security integration systemThere are 3 domains to consider when securing software development.
Description
Secure software development procedure using SCATSee below how the Security code assurance tool integrates security into the phases of software development
How: does the SCAT implement first line of defence
Preparation phaseWhen developing secure software the SCAT helps development teams
Write secure code
Safely deploy in organisation environmentCreate environment specific security requirementsImport environment specific security requirementsWho uses Secure code assurance tool (SCAT)LicensingA project must be licensed under a community friendly or open source license. For more information on OWASP recommended licenses, please see 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. 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. OWASP XXX and any contributions are Copyright © by {the Project Leader(s) or OWASP} {Year(s)}. RoadmapAs of November, 2013, the highest priorities for the next 6 months are:
Subsequent Releases will add
Getting InvolvedInvolvement in the development and promotion of Tool Project Template 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: |
Project ResourcesThis 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. Project LeaderA 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. Related ProjectsThis is where you can link to other OWASP Projects that are similar to yours. Classifications |