Configuration DSL

Ownership

STIG defines the DSL, defaults, and inheritance behavior. The consumer project owns the concrete values: repositories, source profiles, element groups, native targets, analysis boundaries, and severity thresholds.

Configuration Levels

Configuration is resolved from broad to narrow:

1. project defaults;

2. group defaults;

3. source-profile defaults where applicable;

4. element overrides.

This is the standard STIG pattern: put the common behavior once, then override only the values that genuinely differ for a module.

Project-Level Configuration

Project-level configuration usually lives in the root build and declares:

• repository roots;

• source profiles;

• element groups such as activities, components, or clusters;

• default ASIL or failure thresholds;

• common analyzer-input and analyzer-execution settings;

• common native build defaults.

Use project-level defaults for organization-wide policy and repeated settings.

Module-Level Configuration

Each element module has a stig { element { ... } } block. Keep it short:

• assign the group;

• set the source profile only when it differs from the group default;

• set the native build target;

• set implementation namespace/class names;

• set module-specific topics, annotations, harness files, compilation units, and rewrite rules.

Avoid copying the full reference configuration into every module. Repetition makes later changes harder to review.

Override Rules

An unset element property inherits the value from the nearest wider level. A property set at the element level overrides only that property. For list-like properties, use the DSL's explicit clearing or replacement form when you intend to remove inherited values; otherwise inherited values may still apply.

References

Use these pages for the exact DSL fields:

• Per-element configuration

• STIG Gradle plugin

• STIG Gradle plugin commands

• Dokka API reference for com.stigway.engine.config