Hierarchy and Inheritance Best Practices

Lifecycle uses a hierarchy model of organizations and applications for configuration management. Configuration is set at the highest required level and inherited downwards.

Lifecycle Hierarchy Model

Level	Details
Root Organization	default level for reference policies can be renamed to your organization uses the static ROOT_ORGANIZATION_ID through the API
Repositories (Sonatype Firewall)	container for connect Sonatype Firewall proxy reports only for Sonatype Firewall users
Organization	container used to organize application free form naming can use prefixes and suffixes an internal organization id is set when created the "Sandbox Organization" is created by default
Application	a scan point for analysis and reporting created with a custom PublicID for scripting and scanning free form naming may include version numbers

The following table displays common considerations for organizing your application hierarchy model. The top three (highlighted in yellow) are the most common.

Use case	Details
User access control	applications by business units to mirror directory service groups access is granted, not revoked
Policy differentiation	applications with shared enforcement requirements ie. separating legacy from active development ie. enable enforcement for critical applications
Regulatory requirement	sensitive applications which need to remain isolated deprecated applications where the component data needs to be retained
Shared configuration	common SCM, grandfathering, reporting, and monitoring configuration As part of our inclusive language initiatives, we have renamed this feature to Legacy Violations starting with release 167.
Reporting grouping	grouping application together that need to be in a shared report
Micro-service architecture	individual micro services built as an overall application
Application versioning	monitoring multiple active application versions in development and production

Start with an inventory of your applications

create a spreadsheet of your applications to align with your hierarchy considerations.
use existing naming as much as possible to help with automation in your build environment.
The application PublicID should match your build environment variables.
Renaming and moving applications after they have been created is very time-consuming.
Use application categories to flag applications with common policy considerations.

Avoid using a complicated hierarchy

Start with only the considerations that are most important. Keep it simple.
Avoid overly complicated configurations as that often does not provide any value and will not scale.
Avoid creating busy work that does not provide value

Policies are inherited, they cannot be revoked

Policies will apply to all applications below where they are created.
When a policy applies to a subset of the applications, consider using application categories.

Pilot enforcement using policy action overrides

Enabled enforcement for the entire enterprise is not always appropriate.
Using policy action overrides allows you to start enforcing policy actions for a subset of applications
Set the overrides on the organization level for all the applications under them.

Scope policies to an application category when they apply to only a subset of applications

Keep policies scoped to an application category at the root organization level.

Create policies at the organization or application level when needing a unique requirement

Setting policies on an organization or application level doesn't scale over the long run.
They can lead to duplicative policies and gaps in policy coverage while being confusing to manage.
Typically, architecture policies only apply to a single organization group.
Use application categories to scope policies set at the root organization level when you need a different policy for only some applications.

Using organizations for maintenance tasks

Organizations may be used as a grouping for mixed maintenance purposes.
- To_Review → when an application was onboarded to automatic app creation
- Archive → for when an application is not being scanned but you need to retain the report

Using organization prefixes for sorting

The following special characters can be used in organization names to sort them to the top.
- hyphen (-), period (.), and underscore (_)
- You may also use a space however, beginning spaces are ignored and not included.
- You can use something like 'zzz_' to sort the organization to the bottom.
Keep sub-organizations together using a common prefix.