Six Main User Roles You Should Know When Beginning to Assign Users

When onboarding your developer team, provisioning User Roles can sometimes feel like a daunting task and is often overlooked. Below is a simplified overview of the 6 main roles you will be working with when setting up the Veracode Platform. Find out all user roles and permissions in the full documentation: Understanding User Roles and Permissions. 

Administrator 

Can manage users, teams, Veracode eLearning administration tasks, and SAML settings. An administrator is decided on when your contract is put into place. For security reasons, once an Admin has been created, only they can add new users to the Veracode Platform as well as request additional admins to be added to the Veracode Platform by emailing support@veracode.com with the user's information. (Please make sure the user has been added to the Veracode Platform before requesting admin rights). We usually recommend having at least two admins in case someone is out or leaves the company. 

Security Lead 

Can create, edit, and delete application profiles. Can access Veracode Analytics, reports, and flaw details for all applications. Can submit applications and approve scan requests made by Creators and Submitters. Can assign applications to teams. Can review all applications and scans, including receiving all notifications for these applications and scans, without any restrictions or team assignment limitations. Can allow next-day consultations for an application. Can promote a sandbox scan to a policy scan. Can view the list of applications to which you have access. 

Security lead is almost identical to the Admin role, the only difference is they cannot add users to the Veracode Platform or put in requests for additional admin to be added to the Veracode Platform. 

Creator 

Can create, edit, and delete application profiles, as well as request and delete scans for applications that belong to the user's teams. Can only create application profiles for teams in which the user with the Creator role is a member. Can assign applications to teams. Can allow next-day consultations for an application. Can view the list of applications to which you have access. Can also promote a sandbox scan to a policy scan and delete sandbox scans. You can assign the Creator role for specific scan types or for all scan types. In addition, if your user account is restricted to specific scan types, you can only request scans of that type. 

Generally, you want to limit this role to Admins or Team leads only, the Veracode Platform does not limit the number of application profiles you can create so you want to be cognitive that it's in line with your current contract when creating application profiles. 

Reviewer 

Can access reports and flaw details for applications that belong to the user teams and propose mitigations but cannot access the review modules page. Can review scan results and scan reports for sandboxes. Can view the list of applications to which you have access. 

Submitter 

Can request scans for applications that belong to the user's teams, has access to the review modules page, and can upload binaries. Can view the list of applications to which you have access. Cannot create, edit, or delete applications, or delete scans. If you are a vendor receiving a third-party scan request to submit a scan, you need to accept the third-party scan request first. Can promote a sandbox scan to become a policy scan. Can create, rename, and delete agents and regenerate agent tokens in Veracode Software Composition Analysis. 

The reviewer and the submitter go hand in hand and are what you will be assigning to the bulk of the development team. These two roles will allow the developer to access the Veracode Platform, submit scans under a pre-existing application profile, review the results, and submit mitigations. 

Mitigation Approver 

Can approve mitigations for flaws. Can view the list of applications to which you have access. Mitigation approver tends to be the most common role assigned incorrectly. When you think of a mitigation approver generally, it should be someone who isn't necessarily involved in the development of the application but has the credentials/authority review and accept the risk associated with the mitigations, and a lot of times this can fall onto a program admin or a team lead.