Trust Agent Insights and Actionability Guide

This guide is intended for Administrators and Program Stakeholders to get the most actionable usage from their Trust Agent installation.  

Filters

Starting with the top fold, and before we examine metrics, it’s important to note the filters available (often overlooked!).  They are very useful for drilling down and investigating commits by repo, teams or tags.  A few example scenarios you may wish to investigate are:

• With a repo with a high rate of low trust commits, you can figure out what languages, contributors, teams, etc. need language-specific training
• You can filter out certain teams (e.g. “offboarded teams”) to make data more relevant to active developers

You can combine filters to narrow your analysis. Of particular note is the Time: filter, which defaults to 3 months, but can be expanded to 12 months. Only commits, repos, languages, contributors, teams and tags with commit activity within the specified time period will show on the dashboard. For example, this means that a repo will not show in the list if it doesn’t have a commit within the specified time window, even if we have data for it that is older.

Commit Overview

Percentage of High Trust Commits

This metric displays a single percentage representing the proportion of all code commits within the selected time period that are considered "highly trusted." A "highly trusted" commit adheres to your organization's configurable Trust Agent policy configuration, which is based on the developers’ skill level (individual Trust Score, including a language-specific activity check against the languages detected in the commit) and completion of mandatory training content (Courses, Assessments and Quests). You can see the changes over time by changing the Time selector. 

A lower percentage can signal immediate risk being introduced into your codebase due to current skill gaps.

Actionable Takeaways for Admins:

Refine Policies: Review your Trust Agent “Policy configuration” settings. If the percentage is very high, consider making policies more stringent to truly reflect "high trust", but it may also be the case that your program rollout has been very effective, in which case give yourself a pat on the back! If it's very low, evaluate if the policy is currently too strict or if broader, immediate skill gaps exist across the team.

Contributors Making Commits

This metric displays a total count of (non-unique) developers who have authored at least one code commit within the selected time period. It is an indication of the size of your active developer base contributing code. A lower than expected number could indicate gaps in repository coverage, and a higher than expected number may help uncover previously unknown people writing code and present an opportunity for fuller adoption across your developer base. 

Languages With Commits

This metric displays a single number representing the total count of unique programming languages and frameworks found across all code commits within the selected time period. It offers high-level insight into the breadth of technologies present in your codebase, with a higher number indicating a more diverse tech stack. Changes over time could indicate efforts to replatform or refactor code are progressing (or not). Compare this count to your available and assigned learning content to ensure your program offers relevant learning paths for all active languages and frameworks, identifying any gaps in your coverage.

Repositories with Commits

This metric displays a single number representing the total count of unique code repositories that have received at least one commit within the selected time period. Gain a quick understanding of how many distinct codebases are currently undergoing active development, which helps contextualize overall security efforts. Admins and their stakeholders can compare this number against the repositories covered by their security scanners or other tools to ensure comprehensive coverage. A higher number of active repositories might indicate a need to scale security resources or prioritize which repositories receive the most attention for an in-depth security analysis.

Commit Activity 

This metric displays a time series chart illustrating your commit activity across four categories: Non-code commits, Low trust commits, Moderate trust commits, and High Trust commits. You can view this data as either a percentage or the actual number of commits, providing a dynamic view of how commit trust levels evolve over time.

Non-code Commits ( Grey ): While a small percentage (around 10%) of non-code commits is typical, a consistently higher percentage is also not unusual and there can be several valid reasons for this, including:

• Large amounts of documentation that is automatically updated
• Automated commits to data files (e.g. YAML) by bots
• Large amounts of test data files (e.g. JSON)  being updated by developers
• Automated dependency updates
• Files for languages or frameworks that Trust Agent does not yet support (Trust Agent currently only supports detection of languages and frameworks with content on the SCW platform)

It is usually worth a brief investigation where a high proportion of non-code commits is present since non-code files can introduce vulnerabilities (e.g. issues with cryptography, security misconfigurations, etc.). This can simply be asking the engineering team to spot check a few of the non-code commits. In most cases we’ve seen so far, large numbers of non-code commits have been attributed to the above reasons and should not cause concern, however if there are languages or frameworks not being correctly detected please let us know and we will work with you to update the detection rules. If you are satisfied with the result of the investigation, non-code commits can be easily filtered out by toggling “Hide non-code commits” in the filter bar.

Low Trust Commits ( Red ): A high proportion of low trust commits signifies a critical area for improvement. This often points to developers who are either not using a Secure Code Warrior (SCW) license / not engaging with any training or haven't completed the necessary level of mandated training. Investigate these instances to ensure all relevant developers are on the platform and progressing through their assigned learning paths. 

Moderate Trust Commits ( Yellow ): Moderate trust commits typically mean developers have completed some expected training, but their training might not align with the language of the code they're committing. For example, a developer might commit Python code but have only trained in Java. We recommend first focusing on low trust commits for the biggest reduction in developer risk before tackling moderate trust commits. Whether you try to eliminate moderate trust commits will largely depend on your organization’s risk appetite. While less critical than low trust, moderate trust commits indicate an opportunity to fine-tune training assignments and you can encourage developers to engage with training relevant to the languages they actively work with to move them towards high trust.

High Trust Commits ( Green ): Obviously we want to see a high number of commits being High Trust.  High trust commits indicate that developers are consistently completing necessary training for the languages they're using. Similar to the take-aways mentioned above in the “Percentage of High Trust Commits” section, if the percentage is very high, consider making policies more stringent to truly reflect "high trust." If it's very low, evaluate if the policy is currently too strict or if broader, immediate skill gaps exist across the team. These are controlled by the “Require skill level” and “Assign mandatory training content” settings in the Trust Agent policy configuration. 

Repositories

This section shows Trust Agent metrics by repository. You may not be familiar with all repos, but an engineering or security lead can usually identify the organization’s critical repos. A high percentage of low trust commits in an important repo with known vulnerabilities (from scanners) clearly shows a need for significant rework and developer training, and this data helps build a strong business case. 

Actionable Takeaways for Admins:

Prioritize Critical Repos: Focus on key repositories, especially those with high levels of low/moderate trust commits.

Targeted Training: If a critical repo has low trust commits and known vulnerabilities, configure a specific training program for those developers.

Justify Resources: Use this data (low trust in critical repos + vulnerabilities identified by scanner) to justify training or resource needs.

Languages

This section provides Trust Agent metrics by programming language. It's often useful to sort this view by the "Commit Activity" or “Total Commits” columns to see which languages are most actively used.

Actionable Takeaways for Admins:

Assess Coverage Gaps: Compare the languages with active commits against your available Secure Code Warrior training content. Make sure the right languages are available in your learning programs to align with your organization's tech stack and push your developers to actually take them.

Investigate Low Trust Languages: For languages with consistently low and medium trust commit trends, make sure these languages are available in any learning content that has been specified in the policy. Filtering by these languages with the top-level filters can help determine affected repositories, as well as the contributors or teams making these commits for follow up.

Contributors

This section shows Trust Agent metrics by individual developers. Sort by "Commit Activity" to prioritize key committers. This view helps you understand individual trust levels.

Actionable Takeaways for Admins:

Prioritize High-Volume Committers: Focus on developers with the most commits as their trust levels have the biggest impact.

Identify Untrained Users: Use "Invite non-SCW users" to find developers committing code but not on the platform. Get them onboarded to boost overall trust.

Clean Up User Data: With “Bulk actions > Merge contributors” in the drop down selector, Admins can merge multiple contributors to one account. Merge non-corporate emails or aliases (e.g. users may use personal email addresses, have different email aliases as a result of recent M&A, associations with different  business units or parent company, etc.) to improve data accuracy and link training to the right users. 

This is an important part of Trust Agent initial onboarding for many customers because when email addresses cannot be matched between git and the SCW platform, Trust Agent is unable to determine the training policy compliance of the contributor. Refer to this article for more detailed information on how to merge or map contributor emails.

Teams

This section provides Trust Agent metrics based on developers assigned to Teams in the SCW platform. Note that this will only include data for contributors that were successfully mapped to an SCW learner, and therefore the team information is available.

Actionable Takeaways for Admins:

Investigate Low Trust Teams: For teams with consistently low and medium trust commit trends, make sure the right languages are available for training and encourage devs to complete the required training. Filtering down into these teams can help determine affected repositories, as well as the individual team members making these commits so that they can be followed up.

Tags

This section displays Trust Agent metrics based on any custom grouping or collection of users you've defined using tags within the SCW platform. Note that this will only include data for contributors that were successfully mapped to an SCW learner, and therefore the tag information is available. Similar to "Teams," this view allows you to assess the security posture of specific sets of contributors. Use tags to analyze the trust levels of unique project groupings, initiatives, or cross-functional efforts that aren't represented by standard team structures.

Actionable Takeaways for Admins:

Identify Targeted Training Needs: If a specific tag shows a high percentage of low or moderate trust commits, it could indicate a need to configure tailored training programs for the contributors associated with that tag.

Support Policy Enforcement: Tags can help enforce and monitor security policies for specific types of code or projects, ensuring relevant training is applied and adhered to within those tagged groups.