Skip to main content

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.