Best practices for SCA rollout and adoption

Welcome to best practices for SonarQube Advanced Security. In this video, we'll cover SCA rollout and adoption. First, we'll identify a single team and project to pilot the solution. Then we'll cover how to test your pilot's code and address the risks that pop up all while tracking your workflows. Finally, we'll cover rolling out SCA to the rest of your organization, tracking your organizational progress. We'll also go over a few additional organizational best practices. To go along with this, you'll want to reference the companion course available in the Sonar Learning Center: Managing dependency risks with SCA. This course offers a step-by-step guide on how to perform many of these actions in SonarQube. When starting with SonarQube Advanced Security pilot program, remember Sonar's shift-left mindset. Shifting left shows that by adopting Sonar earlier in your development cycle, you'll start catching issues sooner, allowing you to fix dependency risks before they reach production. Have your developers enable Connected Mode at the beginning of the pilot program. This way developers can stay in their native development tool, and teams can see server-aligned feedback, and address dependency issues directly in their IDE before commits or PR merges. To make this real-time, leverage Sonar's MCP Server to query for dependency risks. Sonar's MCP Server makes code quality and security a seamless part of your AI-assisted workflow. It provides your AI agent or LLM with real-time access to Sonar's analysis engine, allowing it to verify its own suggestions against SonarQube security rules and dependency risks. This helps you catch vulnerable code, bad packages, deprecated libraries, and unsafe coding practices while you're writing code in your IDE. When you're ready to test a solution, pick a single team to pilot SonarQube Advanced Security. Be strategic when selecting this team. The initial analysis of projects for dependency risks will likely create a backlog of issues. So just try and pick a team that you know is committed and will have the time to work through whatever issues pop up. Just select one project for the team to work on and to manage the workload. Define license compliance early. Create separate license profiles for internal services versus distributed SDKs. Allow standard permissive and prohibit strong copyleft license categories, and enforce via quality gates on PRs. There's no one-size-fits-all approach to license compliance. So work with your legal organization to create appropriate license profiles, and periodically review your policies to ensure they remain relevant and effective. You can then spin up a staging build that runs SCA to verify license and vulnerability policy before setting your quality gates on a feature branch and merging to main. This ensures there's no compatibility issues with other parts of your project first. To avoid shutting down ongoing development due to strict quality gates when tackling dependency risks, start by only enforcing quality gates on new code first using pull requests. To ensure no new real risk is added to your code base, a good first start is to add the Severity of a dependency risk is greater than info quality gate condition on new code. When you're ready to start addressing risks, start by prioritizing blocker or high risks. These are the most severe. Work with your development team to evaluate how the risk applies to your code. You may be able to mark them as safe as you research how it effects your environment. Then perform any necessary dependency upgrades or implement any workarounds. Once you've worked with your development team to understand how quickly they can remediate dependency risks and perform upgrades you can then determine how strict your quality gate conditions should be for overall code. Once you're confident that your development team can quickly remediate new dependency risks, you can add a quality gate condition to your overall code, such as Severity of a dependency risk is greater than medium. This ensures that any production code merges with newly discovered high or blocker issues will be blocked, forcing the development team to address them. Using SCA's dependency detailed view, we can identify direct versus transitive dependencies and target the right fix. You can also push a Jira work item from the risk and track changes through a sprint. All the while, document your workflow. Track what works versus what doesn't work and log the most effective fixes. During this stage, you'll want to develop a workflow for fixing third party dependency risks. Updating components to a new version, and managing package updates without breaking your project. Just remember that Sonar provides recommendations for fixes within the product UI. You can also evaluate your code based on maintainer insights. Sonar partners with selected open source maintainers to provide guidance on vulnerabilities. Maintainer insights provide a deeper review of a package that explains why the code is or isn't affected by a reported CVE, confirm if a vulnerability is a false positive, or provide patches for specific components. This helps developers identify risks that are false positives. Now that you've rolled out your pilot project you can expand across your organization gradually, reuse your initial team's processes and notes to onboard more teams and build a risk management culture. As you expand you'll be able to build a culture of dependency management practices throughout your organization. To avoid unmanageable technical debt when you first implement the solution, focus on addressing risks in new code first, then tier your quality gates to gradually resolve issues in a phased approach. You can enforce strict standards on new code first, and then schedule time to address dependency risks in legacy code. To get the full picture of dependency risk management and organization it's recommended to track how the number of risks and their severity dropped across your applications over time. This shows how your developers are reducing risk in your organization and how fast they're eliminating risks as they appear. As you track dependency risk management progress, start to tie your metrics to KPIs, OKRs, or organizational goals. For example, you can track median time to upgrade for high risks and percentage of repositories with only permissive licenses after a license policy rollout. This will create a clear picture of where you were, where you are now, and where you're going. Now we'll go over a few additional practices you can implement to support your team following your initial rollout. You can leverage Portfolios to get a view of all the dependency risks across projects, or your entire organization. Teams may have different standards, and this will allow you to see the packages being used by different teams. Use centralized SBOMs to prepare for critical CVEs. This allows you to identify affected code and notify owners in minutes. Maintain a pre-approved package repo, so developers know which packages are safe. Leverage the web API to auto-generate an SBOM after every production build, and save the SBOM in an artifact repository with retention policies. You can also use the web API to create a risk report. This tells you the severities and issues found in projects and risk history. This data can be used for external reporting and Power BI dashboards to monitor trends. You can also upload your SBOM and SCA reports into your enterprise vulnerability management platform. This allows you to correlate software risks, infrastructure signals, and track them against your patch SLAs. Identify leads for each new practice to champion the changes and assign responsibility for faster execution. Developer leads can own the shift-left adoption and DevOps or SonarQube administrators can own SBOM automations. Rolling out SCA with Sonar's best practices ensures a smooth transition for your development teams. Check out the Sonar Learning Center for more educational content that helps you get the most out of using SonarQube.