Here at Sonatype, we spend a lot of time and energy talking about "security" and DevSecOps, and rightfully so, as we have a strong story in this regard. However, I want to take some time and dig 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 focus 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 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 about 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 more suited for being applied at the organization or application level. Unless you are a small shop, these rarely make sense at the root level. I'll start with one exception, 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 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, it could 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 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. If it IS in the spring framework family, but is NOT one of the two versions we've listed, then the rule fires. If however it is 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. If you want help with the logic, please contact me and I'll try to help.
Curtis Yanko is a Sr Principal Architect at Sonatype and a DevOps coach/evangelist. Prior to coming to Sonatype Curtis started the DevOps Center of Enablement at a Fortune 100 insurance company and chaired a Open Source Governance Committee. When he isn’t working with customers and partners on how ...
Explore All Posts by Curtis YankoTags
Try Nexus Repository Free Today
Sonatype Nexus Repository is the world’s most trusted artifact repository manager. Experience the difference and download Community Edition for free.