Architecture Policies
Architecture Policies
The architecture policies are used to direct development teams to avoid using undesired libraries or encourage them to improve the hygiene of the components they are using. Unpopular or older components without newer versions may hide unknown risks due to less scrutiny from security researchers. They may also hint that a project is approaching the end of its life (EOF) or is no longer supported. The threat level rankings are subjective to your organization's goals.
- Consider creating an Architecture-Banned policy against components that should not be used by your development environment. Use Component Labels to identify the components against this policy would be used to enforce.
| Policy | Threat | Categories | Detection |
|---|---|---|---|
| #### Architecture-Cleanup | 1 | All | The component coordinates match common testing libraries - maven:junit:junit. - maven:ant:ant. - maven:ant:ant. - maven:org.apache.ant:ant: - maven:org.seleniumhq.selenium:* |
| #### Architecture-Quality | 1 | All | The component is older or not popular - Age older than 5 Years - Relative Popularity (Percentage) <= 10 |
Architecture Exceptions
The Architecture Cleanup policy is for components that should not be distributed with an application and are probably included by accident, misconfigured builds, or incorrectly scoped scanning targets. Start by reviewing the scan process during the build and address discovered issues with your development teams. Including development tools in production environments should be avoided wherever possible.
- Consider waiving violations when builds cannot be modified and the organization is willing to expect the risk.