How to Use SD Elements in Subsequent Releases / Changes

After you have modelled an application in SD Elements and used it for an existing or new application, you will have made a major first step in building a secure application. Once you have implemented some of the core security requirements, you will notice a drop in time spent on security in the future as you have built-in controls to address many vulnerabilities.

There are three major reasons why you should continue to use SD Elements after the first usage:

  1. New vulnerabilities and security requirements: Over time researchers may discover new security vulnerabilities that your software may be vulnerable to. Periodically checking SD Elements allows you to proactively address emerging threats and/or compliance requirements rather than waiting for an assessment or intrusion to detect the issue. These issues are typically captured in the "Requirements" & "Architecture & Design" phases of SD Elements.
  2. Securing new features: As you add new functionality you may also introduce vulnerabilities, particularly those outlined in the "Development" phase of SD Elements.
  3. Regressions: Any change to the system may introduce a regression. This means that even if you have addressed all proactive security controls today, one or more of those controls may be accidentally eliminated. Use the tasks in the "Testing" phase of SD Elements to ensure you do not have regressions.

The process you adopt for future changes depends on your risk appetite and tolerance for process overhead.

Option 1: Periodic Re-modelling

The most common option, particularly for new users of SD Elements, is to wait a period of 3, 6, or 12 months before using SD Elements again for an application. This introduces more risk as new vulnerabilities may crop-up between releases, but involves less overhead. Since most organizations do not have security requirements at all prior to SD Elements this is still a good option.

For this option, you simply create a new release of a project and go through the tasks in the same manner as you did for the first release.


Option 2: Every Sprint / Change

If you have a lower tolerance for risk, you may consider using SD Elements for all code changes. In agile development, this can involve creating a new release for every sprint. Depending on your tolerance for overhead, you may want to filter for only high priority tasks to reduce the size of the task list.

For an individual change, you can do one or more of the following:

  • Specify the security constraints up-front in the ticket. You can do this by reviewing all or just the high priority development phase tasks in SD Elements and including the relevant tasks in the acceptance criteria / definition of done for that ticket:

  • Include review of security tasks in the code review process
  • Ensure you have automated and/or manual test cases that cover all in-scope tasks in the development phase of SD Elements

In this case, you would continuously leave the development tasks as "TODO" until you finish development or create a new major release.

Note that you should still periodically (e.g. annually) create a new release of the application to ensure you didn't introduce any regressions in the requirements/architecture & design phases.

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