Here at Sonatype we spend a lot of time and energy talking about 'security' and DevSecOps and rightfully so as we have a very strong story in this regard. However, I want to take some time and dig a little bit deeper into our least talked about persona that can benefit from an automated policy, the Architects. Whether you're an enterprise architect or an application architect I think you'll find some interesting things you can make the IQ server do for you.
Out of the box, our sample policies are focused on Licensing, Security, and component age for the most part. I'm guessing most architects might find component age an interesting technical debt discussion but maybe the not the killer use case that sparks the imagination. So let me share a few idioms I've shared in my training classes to see if they don't spark some conversation around ways architects might enforce design contracts or simply standards.
Before I go any further let me say that I see these types of policies as being more suited for being applied at the organization or application level. Unless you are a really small shop these rarely make sense at the root level with one exception which I'll start with, how to ban a whole family of components, in this example I'll pick on log4j. Perhaps your shop has decided to standardize on slf4j and as such you don't want any of the developers accidentally introducing log4j. Using a match on maven coordinates we can look for anything within a given groupID and flag it.
This is fairly straightforward and as shown might even lend itself to a root organization level Firewall type policy. At the Org or App level you'd want to drop the fail on proxy action.
Now let's take that and extend it to make another common question we get from customers. How can I standardize on just 2 versions of a framework like spring? Essentially they have apps using both 3.x and 4.x of the spring framework and want to ensure that only the approved versions are being used. In this case the approved versions should be only the latest patch level release. I figure they patched it for a reason and we want their latest version to minimize the defects we're inheriting from the project.
This one is a bit tricky from a logic standpoint so I'll walk through it. The first constraint checks to see if the component is a part of the spring framework. If it is, then the next two constraints test to see if it is an approved version. This rule will only fire if all three constraints are true so if it IS in the spring framework family but is NOT on of the two versions we've listed then the rule fires. If however it is one one of the versions listed, that constraint is no longer true and the rule doesn't fire.
Hopefully these two examples can spark the imagination about other potential use cases and if you want help with the logic feel free to reach out to me and I'll try to help.