ABacchi035478 (Community Member) asked a question.
How do you define your teams? Are you worried if they are too broad a bad actor could see vulns for apps they shouldn't?
I'm trying to find the balance between having 1000+ teams with "Joe and Bob" in them, and having 20 teams with 500+ users in each.
How have you set your mind at ease between those two types of scenarios? especially when individuals move from role to role within the organization and change teams?
Are you worried if teams are too broad a bad actor could see vulns for apps they shouldn't be seeing and potentially use that to exploit it in the wild?
.png){kind=logo}
Not sure I really understand the question/comment. As far as teams go, we have a small shop each deveoper is responsible for the code they support, sometimes we create them a sandbox, sometimes their code gets roled into the application, somebody from Security team must organize the process with scans, preferablly run the scans after they get the binaries from the developer, then send results back to developer to correct, from that point on the developer should work with the security guy to mitigate the issues, that way we have a seperation of duties and someone is help accountable to get stuff fixed.
One thing is for certain, team structure will likely change over time! There are arguments for large teams and arguments for small teams, depending upon circumstances and business requirements. If a developer has commit access to a repo, then someone considers the developer trusted. SAML is there to boot a user when the company nukes his/her network access. A lot of small Teams will limit the blast radius of a bad actor. It will also result in more administrative activities. Over time, I've noticed a tendency for larger teams, even though I organize them based on the needs of the business unit (knowing I can keep reporting accurately rolled up and drilled down). Within my Org, smaller teams w/in business units can be the result of restricted access requirements, compliance, or contractual stipulations. These are the exception instead of the rule.
Regardless of team, it important to provide accurate reporting to show the business value of your AppSec Program. The dashboards should be reflective of organization hierarchy: Enterprise, Business Unit, Departments, Systems, Teams, etc. Keep the defined Veracode Organizational Unit flexible to adjust to any change the business might throw at you, so you can always provide an accurate dashboard to each layer of the organization.
You could organize around product teams, program, or portfolio. Veracode has the concept of Business Units, Teams and Tags to help. I treat teams similar to groups in Active Directory. To where only users in a particular group have access to applications associated with the group. While it is possible to associate applications with many teams, I only associate a single application profile with a single team for reporting purposes. Just like AD, a developer can have access to multiple AD groups (Veracode Teams).
Thanks for your feedback- My program has the goal of serving our customers(developers) with self service and automation- I am most likley going to go down the route of smaller teams that they stand up on their own via a form and align them to business units in the system for better aligned reporting.
I am going to poke around with the API to script a way to pull the existing team list from the platform and post that to a confluence page or something similar for folks to understand what teams already exist because I dont think they have access to that type of list from the platform out of the box.