A single development phase task can span multiple parts of the code and affect several different developers at the same time. In agile terminology, these are "constraints" rather than user stories. There are a few different strategies on how to consume development phase tasks. You should select the most appropriate strategy or combination of strategies for your development team. In many cases, development teams will select elements of two more strategies to cover off different tasks.
Ticket Annotation Strategy
In this strategy, you review the list of development tasks in SD Elements and append the appropriate ones to an individual ticket (i.e. bug, story, epic, change, etc.) in the ALM tool or business requirements document. Reviewing the list of all development tasks may be onerous, so a modified approach is to filter by high priority only. For agile user stories, the list of tasks can appear under the acceptance testing / definition of done. You can export a list of development tasks to CSV to simplify the process of copying and pasting task IDs and names.
Example of task annotation strategy in JIRA, a common Application Lifecycle Management tool
Task Assignment Strategy
In this strategy you simply assign a Development phase task to an individual developer just like a Requirements phase task. The individual developer takes responsibility for coordinating with other developers to ensure the task is completed. For example, if the task is "Validate all forms of input", the developer discusses the need with individual developers during development to make sure they have included it. In this strategy, you usually assign a single person to handle all the development phase tasks.
Code Review Strategy
In this strategy you do not attempt to add development tasks up-front in the process. Instead, you check the development tasks as part of a manual code review process. As with the ticket annotation strategy, you may elect to focus on high priority tasks only by using a filter. The idea behind this strategy is that development tasks are usually not as difficult to fix after-the-fact as the requirements and architecture and design phase tasks.
If you use a supported ALM tool such as JIRA, you can set the development phase tasks to have a certain tag such as "code review" in the system level configuration. This way you can pull up a list of all of the development phase SD Elements tasks in JIRA during code review.
In this strategy you rely on automated and/or manual testing to verify the absence of vulnerabilities related to development phase tasks. In this case, nobody is actively reviewing the development phase tasks until security testing. This approach is particularly effective for organizations that have highly optimized static analysis setups. You should understand the limitations of automated testing processes: in particular, are there any important security issues that your scanner is missing. You will either want to create automated test cases, custom rules for your static analysis engine, or supplement with manual test cases. You may also want to combine with the code review strategy to cover the cases that are not checked by a scanner.
If you use a scanner for testing, you should have that testing tool automatically mark passed tasks as complete.
A particularly effective strategy for dealing with development tasks is to make them happen by default. For example, many modern web frameworks automatically escape text to prevent against Cross Site Scripting (XSS). The more a framework implements security controls by default, the less you have to worry about developers going out of their way to build security controls. You may wish to mark these tasks as complete at the onset of the project or consider customizing rules so that the tasks to do not even appear if the developers are using that particular framework.