|
|
| (406 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;" | |
| | | | |
| − | <span style="color:#ff0000"> | + | ==What is the Secure code assurance tool (SCAT)== |
| − | Instructions are in RED text and should be removed from your document by deleting the text with the span tags. This document is intended to serve as an example of what is required of an OWASP project wiki page. The text in red serves as instructions, while the text in black serves as an example. Text in black is expected to be replaced entirely with information specific to your OWASP project.
| + | <h1><b>What is the SCAT</b></h1> |
| − | </span> | |
| − | ==Project About==
| |
| − | <span style="color:#ff0000"> | |
| − | {{Template:Project_About
| |
| − | | project_name=Software Integration System
| |
| − | | leader_name1=Michael Bergman
| |
| − | | |
| − | }}
| |
| | | | |
| | + | [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] |
| | | | |
| − | ==OWASP Tool Project Template== | + | ==What is the SCAT== |
| − | <span style="color:#ff0000">
| |
| − | This section should include an overview of what the project is, why the project was started, and what security issue is being addressed by the project deliverable.
| |
| − | </span>
| |
| | | | |
| | + | <ul> |
| | | | |
| − | <p> | + | <li>SCAT is a <span style="text-decoration:underline;">process integrity tool</span>, implementing a consistent, authorized and auditable software development process |
| − | == <b>Introduction</b><br> == | |
| − | There are 3 domains to consider when securing software development.
| |
| − | <ol>
| |
| − | <li><b>The secure software development process</b>: .......</li>
| |
| − | <li><b>Developing secure code</b>: Helping the development team build secure software</li>
| |
| − | <li><b>Continuous improvement</b>:..........</li>
| |
| − | </ol>
| |
| | | | |
| − | <br> | + | <li>SCAT is used by development teams to build, verify and assure secure software |
| − | This OWASP project focuses on the Developing secure code domain and details the why and how behind the Secure software assurance tool.<br>
| + | <ul> |
| − | 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.
| + | |
| − | <br> | + | <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><strong>Verify</strong>: uses a combination of manual test plans and SATS tools to guide and verify correct implementation |
| | + | |
| | + | <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> |
| | + | </li> |
| | + | </ul> |
| | | | |
| − | == Why the Secure software assurance tool==
| + | <li>SCAT is <span style="text-decoration:underline;">not a point in time security verification tool </span>for detecting vulnerabilities after development</li> |
| − | === Secure software development has a number of stakeholders.===
| + | </ul> |
| − | <ol>
| |
| − | <li><b>IT risk</b>: I need to know where my highest risks are, so I can focus on mitigating these</li> | |
| − | <li><b>Information security</b>: I need to generate a list f security requirements to protect against vulnerabilities</li>
| |
| − | <li><b>Compliance and Assurance</b>: I need to ensure the code meets security requirements and we have evidence proving that</li>
| |
| − | <li><b>Business</b>: I need to get the functionality to the market before our competitors </li>
| |
| − | <li><b>Development teams</b>: I need to do all of the above and within a two week sprint cycle :-)</li>
| |
| − | </ol> | |
| | | | |
| | + | ==Process integrity and point in time tools: How they work in the SDLC== |
| | | | |
| | + | [[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]] |
| | | | |
| − | <br> | + | <h1><b>Technical Description</b></h1> |
| | | | |
| − | == <b>What does a secure software development process look like for these stakeholders</b><br>== | + | ==Without further complicating development environment== |
| − | For every sprint cycle
| + | <ul> |
| − | <ol>
| |
| − | <li><b>IT risk</b>: Needs to understand the functional requirement and <b>identify the risks associated</b> with implementing it</li>
| |
| − | <li><b>Information security</b>: Needs to understand the technology behind the functional requirement and its associated risks. Then <b>generate a list of security requirements</b> to protect the technology against exploitation</li>
| |
| − | <li><b>Development teams</b>: Need to <b>implement</b> the technology, <b>test it and record evidence</b> proving the security requirements are met and </li>
| |
| − | <li><b>Approvers</b>: Need to review testing evidence against the organisations risk tolerance levels. Then <b>accept the risk associate with the functional requirement</b> by approving the release</li>
| |
| − | <li><b>Compliance and Assurance</b>: Need to review the testing evidence collected by the development teams and <b>verify its consistency, traceability and quality</b></li>
| |
| − | </ol> | |
| | | | |
| − | <br>
| + | <li>SCAT is a simple 5 screen MVC, C# web application with a small footprint that can be deployed without further complicating development environment |
| − | == <b>Why is it so hard to meet these stakeholder requirements?</b><br>==
| |
| − | <ol>
| |
| − | <li><b>Huge body of security knowledge</b>: Development, security, risk, compliance and assurance teams need to combine their GDPR, ISO, risk tolerances level, OWASP ASVS, security testing, JAVA and .Net knowledge, filter it, and apply it to critical application functions</li>
| |
| − | <ul>
| |
| − | <li><i>Solution</i>: A tool that centrally stores environment relevant GDPR, ISO, risk tolerance level, OWASP ASVS, security testing, JAVA and .Net security requirements</li>
| |
| − | <li><i>Benefit</i>: Centrally storing the security information will be a big once of effort that needs periodic review, but will speed up the requirements generation process make it consistent and repeatable. The more dev teams you have the bigger the benefit </li>
| |
| − | </ul>
| |
| − | <li><b>Complex environments</b>: Most organisational IT environments consist of many moving parts, e.g. rapidly evolving development languages, cloud vs on premise. These require continuous security effort and strains already scares security resources</li>
| |
| − | <ul>
| |
| − | <li><i>Solution</i>: A tool that maintains an internal mapping of which security requirements apply to which risks, technologies and application critical functions</li>
| |
| − | <li><i>Benefit</i>: Creating this mapping is again a big once of effort that needs periodic review, but will result in a filtered list of security requirements, giving clear and consistent security guidance across the various technical environment components</li>
| |
| − | </ul>
| |
| − | <li><b>Huge number of complex security requirements</b>: Development teams do not understand the complicated security requirements, let alone know how to implement these in code and test them after. Also, the flexibility of development languages and different experience levels of developers almost guarantee that every dev team will implement the security requirement differently</li>
| |
| − | <ul>
| |
| − | <li><i>Solution</i>: A tool that stores a language specific and approved secure code building block against each security requirement, guiding the developers on how to implement the security requirement constantly</li>
| |
| − | <li><i>Benefit</i>: Developing these secure code blocks will be a big once of effort that needs periodic review, but will help with the consistent implementation of security requirements across teams, technologies and critical application functions</li>
| |
| − | <li><i>Solution</i>: A tool that stores a set of OWASP tests against each risk, guiding the testing team on how to correctly validate the security requirement has been met</li>
| |
| − | <li><i>Benefit</i>: Developing scripts for these tests will be a big once of effort that needs periodic review, but will help with maintaining a consistent quality of risk testing across teams, technologies and critical application functions</li>
| |
| − | <li><i>Solution</i>: A tool that allows developers to run an "on demand" OWASP ZAP basic scan on their code to verify they have correctly implemented the security requirements</li>
| |
| − | <li><i>Benefit</i>: Immediate feedback loop</li>
| |
| − | <li><i>Solution</i>: A tool that allows developers to open an "on demand" risk training sandbox environment. Allowing developers to learn how to exploit and defend against the risk</li>
| |
| − | <li><i>Benefit</i>: On demand, hands on environment specific training</li>
| |
| − | </ul>
| |
| − | <li><b>Lengthy and cumbersome approval process</b>: Once development has been completed, the approvers need to wade their way through hundreds of automated test results looking for the results relevant to the the functional requirement. This is a lengthy process and blocks the release which almost nullifies the benefit of CI\CD</li>
| |
| − | <ul>
| |
| − | <li><i>Solution</i>: A tool that centrally stores testing evidence alongside the risk and application critical function</li>
| |
| − | <li><i>Benefit</i>: Approvers can see at a glance whether or not the application critical function and its associated risks have been tested and mitigated according to risk tolerance. Speeding up the approval process and maximising the benefit of CI\CD efforts</li>
| |
| − | </ul>
| |
| − | <li><b>Risk management of the application landscape</b>: Risk managers have difficulty assessing the highest risk across the various technologies and and development languages in their environment. Therefore cannot prioritise their efforts and track mitigation efforts</li>
| |
| − | <ul>
| |
| − | <li><i>Solution</i>: A tool that provides a dashboard view of applications, the associated critical functions and the risks exposed by those critical functions. Then shows the number of secure code block and tests to mitigate the risk of exploitation</li>
| |
| − | <li><i>Benefit</i>: Risk managers can easily see which application critical function and which risk needs extra secure code blocks and testing effort. And see how that effort will impact the entire application landscape</li>
| |
| − | </ul>
| |
| − | </ol>
| |
| − | <br>
| |
| − | <span style="color:blue">
| |
| − | <b>The secure coding tool provides the functionality listed above. Helping stakeholders firstly define and include their security requirements and secondly helping them realise and monitor it. In summary the secure coding tool attempts to fill the shoes of a first line of defence for the secure software development process</b>
| |
| − | </span>
| |
| | | | |
| − | ==Description==
| + | <li>Integrates with Jira and runs ZAP and SonarQube in docker containers |
| − | <span style="color:#ff0000"> | |
| − | This is where you need to add your more robust project description. A project description should outline the purpose of the project, how it is used, and the value it provides to application security. Ideally, project descriptions should be written in such a way that there is no question what value the project provides to the software security community. This section will be seen and used in various places within the Projects Portal. Poorly written project descriptions therefore detract from a project’s visibility, so project leaders should ensure that the description is meaningful.
| |
| − | </span>
| |
| | | | |
| | + | <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> |
| | | | |
| − | <br>
| |
| | | | |
| − | == How does the Secure coding tool work?==
| |
| − | <ul>
| |
| − | <li>It is a light weight piece of software designed to be accessed from the developers box</li>
| |
| − | <li>Guides the development team towards meeting stakeholder requirements<br>
| |
| − | <li>See below how the secure coding tool supports the development team through the software development phases<br>
| |
| − | </ul>
| |
| | | | |
| − | == Secure software development procedure ==
| + | <h1><b>See how developers use SCAT</b></h1> |
| − | <ul>
| + | See below how the Secure code assurance tool integrates security into software development phases |
| | | | |
| | + | ==Sprint planning phase == |
| | + | <b>Objective</b>: Ensures security requirements are understood <br> |
| | | | |
| | + | <ul> |
| | + | <li><b>Developers</b> use the <b>Identify risks</b> screen to<br> |
| | + | <ol> |
| | + | <li>Select the critical function to developing/changing</li> |
| | + | <li>Identify the technologies used</li> |
| | + | <li>Automatically generate the security requirements and tests</li> |
| | + | [https://youtu.be/Gpk4K5keLyw 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 to<br> |
| | + | <ol> |
| | + | <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> |
| | + | </li> |
| | + | </ul> |
| | | | |
| | + | == Development phase == |
| | | | |
| − | === <li>Sprint planning phase</li> ===
| + | <b>Objective</b>: Ensure correct implementation of security requirements<br> |
| | <ul> | | <ul> |
| − | <li><b>Developers</b> use the <b>Application risk</b> screen<br> | + | <li><b>Developers</b> use the <b>Secure development</b> screen to<br> |
| | <ol> | | <ol> |
| − | <li>To identify the technologies used to implement this application critical function</li> | + | <li>View and understand how to attack and prevent the risk</li> |
| − | <li>The secure coding tools internal mapping will automatically list the security requirements associated with using this technology</li>
| + | <li>View the secure code requirements</li> |
| − | [https://youtu.be/WQVzthyGL4U Identify technologies associated with application critical function]
| + | <li>View the secure code block to implement the security requirement</li> |
| | + | <li>Manage development effort in Jira</li> |
| | + | <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>Development phase</li> === | + | |
| | + | == Secure code review 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>Code reviewers</b> use the <b>Secure code review </b> screen to<br> |
| | <ol> | | <ol> |
| − | <li>To see and understand how to attach and prevent the risks associated with the critical function</li> | + | <li>Guide manually secure code review</li> |
| − | <li>To do some basic exploitation train (example)</li>
| + | <li>After manual secure code review run a Sonarqube scan to verify security requirements have been correctly implemented</li> |
| − | <li>To see the secure code requirements to protect against exploitation</li>
| + | [https://youtu.be/ygre0SrWxD4 See how the tool verifies correct security requirements implementation] |
| − | <li>To see the secure code block to guide developers to implement security requirement</li>
| |
| − | <li>After development run a ZAP basic scan to verify security requirements have been correctly implemented </li>
| |
| − | [https://youtu.be/Rp5Tr_vBxB0 Secure development]
| |
| | </ol> | | </ol> |
| | </li> | | </li> |
| − | </ul>
| + | </ul> |
| | + | |
| | + | == Testing phase== |
| | | | |
| − | === <li>Testing phase</li> ===
| + | <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>Associate an automated testing tool with the test plan. The secure coding tool allows testers to bulk update test results form the testing tool</li>
| + | <li>Manage testing effort in Jira</li> |
| − | <li>To attach testing result to the test as control assurance evidence proving the risk has been mitigated</li>
| + | [https://youtu.be/QdbCzheceUw See how the tool helps testers test risk mitigation efforts] |
| − | <li>The secure coding tool does not integrate with any testing tools other than OWASP ZAP. Testing results are generated outside of the secure coding tool and manually stored</li> | |
| − | [https://youtu.be/VixapzUB_ts Secure testing] | |
| | </ol> | | </ol> |
| | </li> | | </li> |
| | </ul> | | </ul> |
| − | === <li>Approval phase</li> === | + | == Approval phase == |
| | + | |
| | + | <b>Objective</b>: Streamline the approval and audit process<br> |
| | + | |
| | <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 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 Streamline the approval process] | + | [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>Developers</b> use the <b>Application risk</b> screen<br> | + | <li><b>Risk managers</b> use the <b>Application risk exposure</b> screen to<br> |
| | <ol> | | <ol> |
| − | <li>To see the number of security tests for each risk, and the percentage that have test results. This allows risk team to determine where extra testing effort is required</li> | + | <li>View each application critical function and the associated risks</li> |
| − | <li>To see the number of security requirements for each risk, and which of those requirements have secure code block associated to guide developers towards correct implementation</li> | + | <li>Identify where mitigation effort is required by viewing which risks require security requirements</li> |
| − | [https://youtu.be/8pKxorPSq_M Overview of application landscape and test coverage] | + | <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] |
| | </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 |
| | | | |
| − | </ul>
| + | == Standard secure code requirements== |
| | | | |
| − | == Tool setup==
| |
| | <ul> | | <ul> |
| − | | + | <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> |
| − | [[File:Internal mapping.png|thumb]]
| |
| − | <li>Tool setup<br> The tool lists all application critical functions. <br> | |
| − | And for each critical function it maintains an internal mapping that details the technologies, risks, security requirements, secure code blocks and tests. <br>
| |
| − | A basic mapping exists in the tool but needs to be customised for your environment.</li>
| |
| − | <ol>
| |
| − | <li><b>InfoSec, testing and development teams</b>: Use the tools OWASP data mapping screen to modify the internal mapping. </li>
| |
| − | </ol>
| |
| − | </ul>
| |
| − | <br>
| |
| | <br> | | <br> |
| | + | <li><b>Information security and development team</b> use the <b>Internal mapping </b> screen to |
| | + | <ol> |
| | + | <li>Map the security requirements to OWASP risks</li> |
| | + | <li>Map organisation approved secure code blocks to security requirements</li> |
| | + | <li>Map security test plans to OWASP risks</li> |
| | + | [https://youtu.be/EkWdAC1sbkE See how to setup the SCAT's internal mapping] |
| | + | </ol> |
| | + | </li> |
| | + | </ul> |
| | | | |
| | + | == Client specific architectural requirements== |
| | | | |
| − | <br> | + | <ul> |
| − | <b>What does the Secure coding tool do?</b><br> | + | <li>To generate these requirements we perform a risk assessment on client application landscape and identify</li> |
| − | The secure coding tool, goes beyond theory and procedure and attempts to implement a planned control integration effort.<br>
| |
| − | The Secure coding tool is written in MVC \ MySQL and consists of 5 screens each serving a specific stakeholder
| |
| − | | |
| − | [[File:OWASP data flow.png|thumb]]
| |
| | <ol> | | <ol> |
| − | <li><b>Information security stakeholder</b>: Filters the security requirements according to the functional requirement: Streamlining security requirements generation </li> | + | <li>Critical applications and functions</li> |
| − | <li><b>Dev team stakeholder</b>: Provides secure code blocks to implement the security requirement: Providing code level guidance for developers towards correctly implementing security requirements</li> | + | <li>Risk associated with each critical application function</li> |
| − | <li><b>Dev team stakeholder</b>: Provides security test plans to testing the security requirements: Guiding testers towards correctly verifying security requirements are met</li> | + | <li>Architectural security requirements to secure each critical application functions</li> |
| − | <li><b>Compliance and assurance stakeholder</b>: Provides a central store for testing results: Promoting traceability through requirements and serving as a quick reference screen for assurance to view control assurance evidence, speeding up the approval process and minimising its impact on responsiveness to market</li> | + | <li>Client specific secure code blocks to implement security requirements</li> |
| − | <li><b>IT risk stakeholder</b>: Provides IT risk with an overview of each applications exposure to OWASP TOP 10 risks: Informing risk based decision making and prioritising</li> | + | <li>Secure test plans to verify risk has been mitigated</li> |
| | </ol> | | </ol> |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| | <br> | | <br> |
| − | <b>How does the secure coding tool do it?</b><br> | + | <li><b>Tool administrators</b> use the <b>Internal mapping </b> screen to |
| − | The secure coding tool, goes beyond theory and procedure and attempts to implement a planned control integration effort.<br>
| |
| − | The Secure coding tool is written in MVC \ MySQL and consists of 5 screens each serving a specific stakeholder
| |
| | <ol> | | <ol> |
| − | <li><b>Information security stakeholder</b>: Filters the security requirements according to the functional requirement: Streamlining security requirements generation </li> | + | <li>Create json files of the organisation specific risks, security requirements, secure code blocks and tests</li> |
| − | <li><b>Dev team stakeholder</b>: Provides secure code blocks to implement the security requirement: Providing code level guidance for developers towards correctly implementing security requirements</li>
| + | <li>Import these into the SCAT</li> |
| − | <li><b>Dev team stakeholder</b>: Provides security test plans to testing the security requirements: Guiding testers towards correctly verifying security requirements are met</li> | + | [https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests] |
| − | <li><b>Compliance and assurance stakeholder</b>: Provides a central store for testing results: Promoting traceability through requirements and serving as a quick reference screen for assurance to view control assurance evidence, speeding up the approval process and minimising its impact on responsiveness to market</li>
| |
| − | <li><b>IT risk stakeholder</b>: Provides IT risk with an overview of each applications exposure to OWASP TOP 10 risks: Informing risk based decision making and prioritising</li>
| |
| | </ol> | | </ol> |
| | + | </ul> |
| | | | |
| | <br> | | <br> |
| − | For a more detailed look at the inner workings of the tool and a brief instructional video please take a look at my linkedIn article<br>
| + | <br> |
| − | <b>[https://www.linkedin.com/pulse/secure-coding-tool-michael-bergman/ Secure coding tool]</b> | + | |
| | + | <h1>Project information</h1> |
| | | | |
| | ==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 © 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== | + | == Interested in contributing== |
| − | <span style="color:#ff0000">
| + | [https://www.linkedin.com/in/michael-bergman-99826212a/ Please send a connect request with subject SCAT] |
| − | 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;" |
| |
| | | | |
| | == 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]
| |
| − |
| |
| − | [https://github.com/SamanthaGroves Source Code]
| |
| − |
| |
| − | [https://github.com/SamanthaGroves What's New (Revision History)]
| |
| − |
| |
| − | [https://github.com/SamanthaGroves Documentation]
| |
| | | | |
| − | [https://github.com/SamanthaGroves Wiki Home Page] | + | [Installation Package] |
| | | | |
| − | [https://github.com/SamanthaGroves Issue Tracker] | + | [Source Code] |
| − | | |
| − | [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>
| |
| − | | |
| − | | |
| − | | |
| − | == 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== |
