How to Review an Existing Application in SD Elements

If your application already exists, and you have modeled it in SD Elements, you can complete the following process to review it against security requirements. Note that if any of the options below do not appear for you, it probably means you do not have sufficient permissions. Contact your administrator for additional permissions.

1. Determine what level of rigour you want to assess the application for. If you want to review all security requirements, then proceed to step 2. If you only want to review the highest priority requirements, open the filter sidebar and select "High (7-10)" in the priority area.

2. Review each task in the Requirements, Architecture & Design, and Development phases on the Tasks page. Determine which category it falls under and mark the status accordingly:

  • You are confident the task is complete, but you are not sure if it is tested. Mark the task as "Done". You may also wish to add a note to provide context for other users.


  • You are confident the task is complete and it has been tested (e.g. through a penetration test, automated analysis, etc.). Mark the task as "Done". Click  the "Verification" tab and click "Add manual verification". Select "Verified Pass" and add a reference note on how it was verified.

Verification ribbon

Marked as "Done" with reference note

  • You are unsure if the task is complete. Leave the task as "TODO". You may wish to document the reasons why you are unsure by adding a note. You may also wish to assign the task to a user to look into. You can do so by clicking on "Assign User" and selecting the user's name. Note, you will first need to add the user to the project through the Overview->Edit page.

  • You know the task is incomplete through a failed test (e.g. a vulnerability discovered in a security audit). Leave the task as "TODO." Hover over the verification tab and click "Verification". Select "Verified Fail" and add a verification note on how you know the task was not completed.



  • The task is not relevant to the application. Mark the task as "N/A". Leave a note explaining why you marked it this way.

3. If you have scanned the application with a supported security scanning tool, you can import the results. You may wish to mark any tasks which were verified as Pass or as Done. You may also wish to mark any tasks which were verified as Fail as TODO. 

4. Now you can focus on the tasks still marked as TODO. At this point, you may want to integrate the TODO tasks with an ALM tool. For each TODO task, you can either verify whether or not it has been completed through code review or through manual testing. You can find the testing steps by clicking on the "Related Tasks" link and reviewing all related tasks in the Testing phase. 

5. Any requirements which have not been met should become developer tasks in future releases/sprints, or patched immediately as hot fixes depending on the severity. Note that you may not want to address certain requirements for business reasons (e.g. the risk of not meeting the requirement does not warrant the effort to fix it). You should add a note to any such task documenting that the business is explicitly accepting the risk.

6. Depending on the level of security rigour you desire, you can use the testing phase in SD Elements a guideline for a security test. Your security testers should go through each phase in SD Elements and mark each testing task that they have completed as "DONE". They can use the verification flag to specify whether test resulted in a pass or fail. They can also use the "Related Tasks" to mark all passed tasks as "DONE" and all failed tasks as "TODO".






Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request