Reading through the 30/60/90 Day Plan, I couldn't agree more. I think it’s extremely important to identify and prioritize applications but I also think it might be even more important to have an understanding on how you would like to use Veracode at various levels of integration/on-boarding as well. My two additional suggestions might seem a little waterfally but bear with me:

1.    Know how you want to interact with the Veracode Platform with early/half/full integration

Decide what you will want to use throughout various cycles of implementation and on-boarding.

• Are you going to want to leverage reporting at some point?
• Will you use eLearning?
• How would you like to organize teams?
• Will you want to use business units? One app per team? etc
• What role will people play within the system and what do the various user permissions do and what would that look like at various levels of scale?
• Should we use Veracode’s policies or should we customize one?
• How should teams deal with identified vulnerabilities and who can approve/reject false positive claims?

Knowing/thinking about the answers to some of these scaling and on-boarding questions can drastically save you a lot of time and stress later by figuring out how much time will something take you now vs later. For example:

• If you know that you will be wanting to leverage the use of metadata with custom fields for reporting you’ll want to do that early. On-boarding and setting up application profiles and scanning is very easy, however the human element of retroactively adding that data after you’ve on-boarded countless apps isn’t as easy. Trust me, you don’t want to have to email countless teams asking for xyz metadata.
• If you want to change user group access, you can pretty much do that any time.
• If you notice that applications have a common vulnerability, you can assign an eLearning module to those application devs after they’ve shown a history through reporting.

2.    Create a repeatable and mandatory framework for on-boarding applications and users

After determining how you’ll want to interact with Veracode in the process, spend time to create a mandatory (preferably automated) framework based on your requirements. If it isn't mandatory then you'll have some applications/teams causing a backlog of work for you to fix later. Here are two of many possible examples:

• You want to leverage reporting but want to add/use custom metadata fields
  • Before you get started on-boarding applications and not requiring certain data, require all teams to provide this data before the application profile is created in Veracode. However, by allowing any user to create their own apps in Veracode they can miss where they should put the metadata, and worst of all there is no data validation. So, I suggest removing the ability for end users to directly create application profiles and either creating an automated process for teams to request new application profiles which require your required metadata fields (we’ve leveraged forms, custom api wrappers, etc) or having specified admins creating these profiles for them. This is helpful because

1. You will be able to report cleanly and efficiently
   1. You can identify stakeholders, application owners, application scope more easily to help prioritize, organize and determine risk.
   2. Key reporting / identifying data is on every application profile so you won’t have to search for it if something goes wrong.

• You want to restrict access to application profiles and actions that users can do within the platform
  • Having forethought on how you want different types of users to interact with the platform is crucial, with this you will know what teams and actions these users will have access to. By dissecting your user base into different groups, you can easily identify respective requirements. For example, an infosec personnel can have access to the security lead permission and not be tied down to a team. On the flip side a basic developer would only need access to a specific team and only need to scan. Once you know this you can start to integrate into your access management processes and require those certain group permissions rather than having to assign them individually.

TL;DR: Knowing how you’ll want to interact with Veracode at various steps in the process will help you prioritize which steps to automate first to have quick and consistent on-boarding of new teams/users/applications. This will allow your team to focus on vulnerabilities at both micro and macro levels rather than having to hand-hold teams/applications/users through the on-boarding process.

What we found useful when onboarding new applications and teams to the Veracode Platform was a required data (metadata) collection form that provided us a single-stop for all information that we needed about the application and the team supporting it. We asked for the App ID from the Portfolio Management tool, the application name, development team manager name, Security Champion for the application or team, then each team member's information so we could create IDs for them and enroll them in Role-Based AppSec Training (if they had not already completed it) to make sure everyone was trained and certified to work on the application.

Once onboarded, we had a Wiki for the development teams -- on the Wiki platform they use daily -- to help them with the mechanics of packaging and uploading the application, along with a request form to our team if they wanted personal help so they were not left hanging out with remaining questions or confusion on what they needed to do. We did the same for Triaging scans or any other help they needed to become empowered to take on AppSec as a team and as developers on mission-critical applications.

We went through a few versions to the Onboarding Form, but once it had everything everyone on the AppSec needed, the form did not change again in 4+ years of use.

It looks like the question changed a bit, but that's OK - the new one needs answers too!

The BEST advice I would give to someone totally new to Veracode is to think of it as more of a developer's tool than a tool for the Security Group outside of scrum teams. In other words, if developers are convinced that it was developed for developers by developers to help make developers better at their jobs, the teams tend to embrace it and strive to use it, rather than being thought of something 'thrust' upon them by 'those guys' and use it as a checkbox activity. Don't let that happen to you!!

So you asked,

• What was helpful in onboarding with Veracode? having the help doc for compile instructions, actually the doc is very good for many things, being able to generate a xls spreadsheeet of the findings to review with the team, easy UI navigation.
• What was challenging/confusing when you first got started? How did you overcome it?

figuring out how to address all the flaws found, what was best practice for documenting mitigation for all the issues, once we met with the consultant many things cleared up, repeat flaws was frustrating, learning how modules uploaded worked, whether we had captured all the modules for code we developed. Getting a source code inventory was a challenge, I learned to work with the developers on the scan process and addressing flaws found, that was difficult at first but through experience now have a good process.

Software testing is the process of evaluating a software application or system to ensure that it meets specified requirements and performs as expected. It involves executing the software to find defects or errors and ensure its quality, reliability, and functionality.

Software testing typically involves the following key activities:

1. Test Planning: Defining the objectives, scope, and approach for testing. This includes identifying test objectives, test strategy, test deliverables, and resource allocation.
2. Test Design: Creating test cases and test scenarios based on the requirements and specifications of the software. Test design involves determining what to test, how to test, and what data to use for testing.
3. Test Execution: Running the test cases and capturing the actual results. This involves comparing the expected results with the actual results to identify any discrepancies or defects.
4. Defect Reporting and Tracking: Documenting and reporting any defects or issues found during testing. Defects are typically logged in a defect tracking system, and their status is tracked until they are resolved.

Data Science Training in Pune