To establish a better understanding of risk within a paradigm of component management, we need to identify the various avenues of risk a component can have. The most common are security, licensing and architectural considerations.
Of course, we shouldn’t limit our thinking to these three alone, and in the long term you will define those specific to your organization. However, they will serve us well to get started.
When creating policies, we need to consider what risk we want reported and how we want it reported. Take a look at these very simple example policies, one each for licensing, security, and architecture. These are fairly common, and may be something you have in your own organization, even if you haven’t even committed to them with pen and paper.
The above policies represent an organizational intent to not allow GPL highly insecure components. It further qualifies that old components and a specific version of struts are not to be used. In this way, our three policies are actually working together to form and overall policy approach.
As you move on to create your own policies, it becomes very important to think about how policies can build upon each other. In many ways this is a holistic approach, something that rules simply can’t do.
Terms of Service Privacy Policy
Copyright ©
2008-present, Sonatype Inc. All rights reserved. Includes the
third-party code listed here. Sonatype and Sonatype Nexus are trademarks
of Sonatype, Inc. Apache Maven and Maven are trademarks of the Apache
Software Foundation. M2Eclipse is a trademark of the Eclipse Foundation.
All other trademarks are the property of their respective owners.
Sonatype Headquarters - 8161
Maple Lawn Blvd #250, Fulton, MD 20759
Tysons Office - 8251 Greensboro Drive #610, McLean, VA
22102
Australia Office - 5 Martin Place, Level 14, Sydney 2000, NSW, Australia