Skip to content

Integration with CodeScoring.OSA

CodeScoring.Save can be used as an upstream repository for OSA Proxy. In this setup, package managers send requests to OSA Proxy, OSA Proxy checks requested components through CodeScoring.OSA, and allowed requests are routed to the Save proxy repository.

CodeScoring.Save is not connected to OSA Proxy through a separate integration API. To check downloaded components, package managers must be configured to work through OSA Proxy, and OSA Proxy must be configured for the corresponding upstream repository.

If the upstream repository is a CodeScoring.Save proxy repository, its URL is specified in the registry field of the OSA Proxy repository. In this scenario, traffic follows this chain:

Package manager -> OSA Proxy -> CodeScoring.Save proxy repository -> external upstream

OSA Proxy scans packages and manifests, calls the CodeScoring API to check policies, and blocks unsafe components depending on the selected work-mode.

What is configured in OSA Proxy

Configuration is performed in OSA Proxy. For each supported format, the corresponding section is enabled and the list of repositories is specified:

maven:
  enabled: true
  repository:
    - name: save-maven
      scan-manifest: true
      scan-package: true
      work-mode: strict_wait
      url-encoded-config: true
      registry: https://save.example.com/maven/<project>/maven-central-proxy

npm:
  enabled: true
  repository:
    - name: save-npm
      scan-manifest: true
      scan-package: true
      work-mode: strict_wait
      url-encoded-config: true
      registry: https://save.example.com/npm/<project>/npmjs-proxy

codescoring:
  url: https://codescoring.example.com
  token: "<API_TOKEN>"
  work-mode: strict_wait
  osa-proxy-url: https://osa-proxy.example.com
  block-on-codescoring-errors: true
  remove-blocked-versions: true
  block-status-code: 403

For PyPI, packages-registry is specified additionally; for Go, sumdb-registry; for Docker, auth-token-url if the upstream registry requires a separate token service.

Operation Modes

Check behavior is controlled by the work-mode parameter. It can be set globally in the codescoring section or overridden for a specific repository.

Supported modes:

  • warmup — loads data into the CodeScoring cache without blocking components;
  • spectator — loads data into the CodeScoring cache without blocking components and saves component request results in the platform;
  • moderate — blocks components that fail policy checks; unscanned components can still be downloaded;
  • strict — blocks components that fail policy checks; unscanned components cannot be downloaded;
  • strict_wait — blocks components that fail policy checks; unscanned components are checked with waiting.

Limitations

Checks through OSA Proxy apply to traffic that passes through OSA Proxy. For hosted Save repositories, checks must be performed before publishing an artifact or through a separate control process.

Security policies are configured in CodeScoring. OSA Proxy uses the CodeScoring API to scan components, retrieve package information, and check policies, but does not create policies inside Save.

See Also

Страница была полезна?