The role of AppSec teams in DevSec is to act as an enabling team. By providing self-service tools to developers and helping them use those tools, you can scale your security efforts more than if you engaged every team directly.
Security teams can collaborate with developers by giving them self-service tools that are easy to use, fast to run, and accurate on results.
Security is often an enabling team in the team topologies framework. The goal of security is not necessarily to do security, rather its role is to provide tools, techniques, and assistance to do security more effectively.
At other times, members of the security team can embed themselves by joining a stream-aligned development team. This temporary togethes-ness can offer an opportunity to train developers on the security aspects that they need to know that are directly applicable to the main project. The knowledge shared is not just training, it can also be things like how to tag issues, what to document, what to log or not, and other acpects.
As a security professional, your role is not to gate-keep or validate the final deliverable from a development team. While you can still offer services like penetration testing, the primary goal is enabling other teams to handle their own security and know when to ask for help.
Becoming a toolsmith means giving developers tools that automate as many security practices as possible and then providing you expersite for anything further. This frees security teams to focus on business logic concerns beyond what software can understand on its own.
- Provide the tooling and internal support.
- Provide consultations and expertise to understand "security" in context.
- Help monitor and plan remediation goals of identified security issues.
- Integrate tools into the proper SDLC location.
- Integrate findings into tools like defect tracking to plan ahead.
- Remediate/fix security issues per tool/security guidance.
The security groundhog is someone who doesn't participate in any planning but has the opportunity to delay a project at the end. Like a groundhog who pops its head up on Groundhog Day to tell if it sees its shadow for four more weeks of winter, the security groundhog appears at the end of a project to see a risk and declare four more weeks of remediation.