This blog explores the factors that can help a product security team judge the possible security impact of a proposed new feature or development before starting a security review. It is an important task to find this before jumping in to security review.
Why do this ?
- Number of tasks to be performed in a security review can be decided based on this impact analysis.
- Amount of time to be spent in a security review can be adjusted by the product security team member based on this which lead to savings in cycles of usually understaffed product security teams.
- Number of stakeholders to be involved in a security review can be adjusted based on this.
- Security reviews can be distributed to members based on their skill level and this impact analysis outcome.
How to do this ?
I browsed through CWE VIEW: Software Development to see the list of weaknesses around concepts that are frequently used or encountered in software development. I tried to find some important changes that can lead to these weaknesses and put them in a table below.
This is *NOT* an exhaustive list. Idea is to have something which is quick but provides good enough coverage in a small amount of time.
- Note 1 – Actors can be a user, role, service account, process etc.
- Note 2 – Mechanisms can be API, client side apps, file uploads etc.
Conclusion
Above table can help product security decide how much importance and time should be given to a particular feature and can help save some work cycles.
If you think I should add something else to this list feel free to reach out to me on my linkedIn handle.