Service configuration
This page describes the current OSA Proxy implementation. The archived Java/Spring implementation is available in Archived Java/Spring implementation.
OSA Proxy is configured with the osa-proxy.yml file. The example below shows a typical working configuration with several ecosystems, CodeScoring settings, HTTP client settings, Redis cache, and logging.
For CodeScoring versions earlier than 2026.20.0, set codescoring.legacy-judge: true. Versions before 2026.20.0 use the legacy Judge API, while OSA Proxy uses the current Judge API by default.
Configuration example
codescoring section
The HTTP/1.1 status line supports ASCII only. Messages containing Cyrillic or other non-ASCII characters are not passed in the status line. If Nexus or a package manager must display the block reason in the status line, use ASCII characters in block-message, for example Component download blocked by security policy.
Building URLs from forwarded headers
Use osa-proxy-url-from-forwarded-headers when one OSA Proxy instance is available through multiple external URLs, for example from two network zones:
The reverse proxy in each zone supplies its own X-Forwarded-Proto and X-Forwarded-Host. OSA Proxy uses them to build absolute package links in metadata and manifests, so clients in each zone receive links through the URL available to them. For example, requests through osa-proxy.internal.example.com produce links with that host, while requests through osa-proxy.dmz.example.com produce links with the DMZ host.
If X-Forwarded-Proto is absent, OSA Proxy uses https; if X-Forwarded-Host is absent, it uses the regular Host. Enable this mode only behind a trusted reverse proxy that overwrites forwarded headers instead of passing client-supplied values through.
Package manager sections
Each ecosystem contains the enabled flag and a repository list. The repository name becomes part of the OSA Proxy URL:
This repository is available at:
The scan-manifest and scan-package fields enable checks for manifests and downloaded artifacts. With scan-manifest: false, npm, NuGet, and PyPI metadata is not scanned, but links in responses are still rewritten to OSA Proxy. Support depends on the ecosystem; see Supported protocols. Repository-level work-mode overrides global codescoring.work-mode.
Ecosystem-specific options
composer and pypi support packages-registry and additional-packages-registries when artifacts are downloaded from separate hosts. go uses sumdb-registry when SumDB proxying is required. For ivy with scan-package: true, explicitly select a layout: the built-in sbt-default or ivy-default pattern, or a custom pattern from the root layouts section. Docker supports auth-token-url, scan-container, and codescoring-pull-through-proxy.
Repository manager integration
For supported ecosystems, additional options are available for passing JFrog Artifactory repository and user context to OSA Proxy. The appropriate option depends on the Artifactory version and configuration. Vendor support provides details on request.
The artifactory and nexus sections periodically retrieve repository manager inventories and automatically create routes for selected ecosystems. Complete discovery, credentials, URL, repository context, and block response documentation is grouped into separate sections:
Verdict cache
Redis cache is disabled by default:
To enable caching:
Logging
The log level is configured with logging.level. Supported values are debug, info, warn, and error.
Parameter reference
Root sections
Common package manager parameters
Repository-specific parameters
file-type-filter
The filter applies only to non-Docker repositories. It is disabled unless
enabled: true is set, including when the section is {} or either extension
list is populated. When disabled, requests follow the normal handler rules.
When the filter is enabled, OSA Proxy:
- lets metadata/manifest requests pass without extension checks;
- extracts the filename from the URL path, decodes URL-encoded characters, and compares extensions case-insensitively;
- allows a file when its extension is included in the built-in ecosystem preset or in
additional-allowed-extensions; - always allows checksum suffixes
.sha256,.sha384,.sha512,.sha-256,.sha-384,.sha-512,.sha1, and.md5; - allows
.metadataand.ascsidecars only when the base artifact is allowed; - immediately blocks all other package file requests before contacting the upstream registry or CodeScoring.
Built-in presets:
For Debian, source tarballs matching .orig-*.tar.gz, .orig-*.tar.xz, and .orig-*.tar.bz2 are also allowed.
additional-allowed-extensions only extends the filter allow-list. It does not
enable the filter or make the handler scan those files. To make a new file type
participate in package scanning, also add the extension to scanned-extensions.
scanned-extensions controls the second behavior: files with these extensions are treated as scannable package artifacts even if the ecosystem's default strategy does not recognize them. For these extensions, a short-lived scan-result cache is enabled so related files with the same base name can reuse one verdict. For example, Maven can use scanned-extensions: [.jar, .pom] so demo-1.0.0.jar and demo-1.0.0.pom are grouped by the demo-1.0.0 base name.
Example:
In this example, .tgz is allowed by the npm preset and participates in package scanning, while .license is additionally allowed by the filter but does not become a scannable artifact.
npm behavior example
Without the file-type-filter section, the filter is disabled. The npm handler follows its standard logic: the package tarball left-pad-1.0.0.tgz is sent to package scanning, while other requests are handled as metadata or passthrough depending on the route.
An empty section also keeps the filter disabled:
To enable the filter without adding new extensions, set enabled: true. For
npm, only the built-in .tgz preset and applicable sidecars are allowed. A
request for left-pad-1.0.0.tgz passes and is checked, while
left-pad-1.0.0.exe is blocked before upstream and CodeScoring are contacted.
To allow a non-standard file without sending it to package scanning, add the extension only to additional-allowed-extensions:
With this configuration, .tgz is scanned as an npm package, .license passes the filter as an allowed file, and .exe is blocked by the filter.
codescoring
codescoring.resilience.retry
codescoring.resilience.circuit-breaker
http.server
http.client
cache.judge
cache.redis
Complete TLS, corporate CA, Docker Compose, and Helm configuration is documented in Redis and Caching Configuration.
logging
OSA Proxy writes JSON logs. Each inbound request produces one info completion
event named http request completed with component, method, bounded
route, request path without query parameters, status, status_class,
outcome, and duration_ms. When tracing context is available, the event also
contains trace_id and span_id.
admin
For details, see Admin API and management.
configuration-store
For details, see Admin API and management.
layouts
The root layouts section contains a map of custom path layouts for Ivy (sbt) repositories. The map key is the layout name, and the value is the path pattern string:
For details, see Ivy configuration.
webhooks
The webhooks section defines outbound HTTP POST event notifications:
For details, see Webhook configuration.
