What Makes ProGet 2024’s SCA Policies a Users’ Favorite? – Inedo Blog
user

What Makes ProGet 2024’s SCA Policies a Users’ Favorite?

Introduction

Crista Perlton

Crista Perlton


LATEST POSTS

How to Escape Python Script Hell with Modules & Packages 06th February, 2025

Dealing with Fluent Assertions License Changes in ProGet 30th January, 2025

Inedo

What Makes ProGet 2024’s SCA Policies a Users’ Favorite?

Posted on .

Since we released ProGet 2024 we have received a lot of positive feedback on how the reworked Policies & Compliance Rules have really cut down the time spent managing compliance. Our customers have found them to be “intuitive and incredibly effective.”

A particular feature that our users have been really positive about is the Software Composition Analysis (SCA) policies. This was a highly requested feature we added in response to comments and feedback we received on our forums.

In this post, I’m going to dive into how these policies work and why they are essential.

What Are SCA Policies?

SCA (Software Composite Analysis) policies in ProGet let you define what “compliant” means for open-source packages in various contexts. These policies let you set rules regarding licensing, vulnerabilities, and other things like deprecation. When set, they will block downloads or usage of “noncompliant” packages. You can also create exceptions for known packages and “warn” for packages that are somewhere in-between.

Key Components of ProGet’s SCA Policies

Global-Level, Feed-Level, and Shared Policies: ProGet lets you create Global policies that apply to all feeds, feed-level policies that can override global ones, and Shared Policies that can be used across different feeds. These offer a centralized way to manage your compliance rules.

Package Analysis: ProGet performs a package analysis to determine compliance status. This analysis can be triggered manually or scheduled to run automatically. Packages are evaluated against the rules you have defined, and their status is shown as “compliant“, “noncompliant“, or “warn“.

Compliance Rules: A policy contains a number of rules that are used to analyze whether packages are ✔ Compliant, ❌ Noncompliant, or neither (i.e. “⚠ Warn“). The analysis logic gets a little more complicated with rule exemptions and multiple policies, but in all cases, there is a fixed number of pre-defined rules that you can configure on a policy.

Would you like any other rules?

These rules are just the starting point, and we’d love to get your feedback on what else we could add. Perhaps we could even allow users to create their own rules using a plug-in?

As you may know, we are very much user-driven, and have a history of creating new features and products based on customers’ requests, such as ProGet Edge Edition, Pub (Dart/Flutter), and CRAN (R) feeds.

You can reach out to us via our support channel, preferably using the Inedo Forums, so everyone can benefit from the discussion.

Crista Perlton

Crista Perlton

Navigation