Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

WORKING DOC

Authors:

  • Samuli Kuusela
  • Bob Heinemann

Purpose:

The purpose of this investigation to understand ONAP's current security posture regarding dependency management.  If found to be lacking, recommendations will be made to enhance.

Notes from Samuli

The novel types of dependency confusion attacks utilize the way some package managers work (by default). In this case, “A dependency confusion attack or supply chain substitution attack occurs when a software installer script is tricked into pulling a malicious code file from a public repository instead of the intended file of the same name from an internal repository”. Quote from dependency confusion attacks, I recommend you read that very short article.

So my question is, if ONAP SW build process can be improved wrt. this types of attack.
Quote from the same article:

Microsoft’s whitepaper details three ways to mitigate the risk of a substitution attack:

  1. Only use a single private package feed – pull any dependent public packages into your private repository so you can be sure of control. However, this does then mean you need to manually update the public package versions as needed.
  2. Control the scope – if your package manager supports scope control (like npm does) you can prevent internal packages from being retrieved from a public repository.
  3. Client side verification – integrity verification, when enabled in the package manager, will abort the build if an unexpected change is detected in a dependent file.


On the broatopic of SW Supply Chain Security, there is also an evolving specification: SLSA - Supply-chain Levels for Software Artifacts https://slsa.dev/. This is inspired by Google internal code provenance implementation, it’s an evolving thing: https://github.com/slsa-framework/slsa

Notes from Bob

To review this we need to understand the current CI environment and how it is configured. 

The CI environment is provided by LFN and you can see some nice details here.  The chart is very instructive.  Developing ONAP

Accordingly, ONAP's artifact repo is managed by a product named NEXUS.  https://nexus3.onap.org/  I logged into this link but nothing shows up for.  Perhaps I need some permission.

The NEXUS manual has the following description:

Nexus Repository OSS is an open source repository that supports many artifact formats, including Docker, Java™, and npm. With the Nexus tool integration, pipelines in your toolchain can publish and retrieve versioned apps and their dependencies by using central repositories that are accessible from other environments.

  • Single source of truth for all of your components, binaries, and build artifacts.
  • Efficiently distribute parts and containers to developers.
  • Deployed at more than 100,000 organizations globally.

NEXUS Routing Rules

As an administrator of a Nexus Repository Manager instance, you may want to prevent it from making certain requests to upstream repositories. This could be used, for example, to prevent a name hijacking attack where a malicious user creates packages in a registry with names used by your internal projects.


  • No labels