When opening issues focused on quality or security best practices (for example, a security assessment or a code review), it's better to keep them as small as possible. Ideally, these issues are placed on a separate bug-tracking project (like the Security RISK one), since they can cause problems for project managers who like to keep their bug count small.
Since this type of information only exists while AppSec developers are looking at code, if the information isn't captured, it will be lost, either forever, or until that bug or issue becomes active. It is very important that you have a place to put all those small issues, examples, and changes.
Capturing the small issues also helps to capture the high-level and critical security issues that are made of multiple low or medium issues. Their capture also helps to visualize the patterns that occur across the organization, for example, in an issue that effects dozens of teams or products.
This approach also provides a way to measure exactly what will occur during a quality pass or sprint, for example, when focusing on cleaning and improving the quality of the application.
The smaller the issue, the smaller the commit, the smaller the tests will be. As a result, the whole process will be smoother and easier to review.
It also creates a great two-way communication system between Development and AppSec, since it provides a great place for the team to collaborate.
When new developers join the team, they should start with fixing those bugs and creating tests for them. This will help them to understand what is going on, and how the application works.
Fixing these easy tests is also a good warm-up for more complex development tasks.
(from SecDevOps Risk Workflow book, please provide feedback as an GitHub issue)
