From 802c2f24ccab8e7f3c6d030a830f7756e649e985 Mon Sep 17 00:00:00 2001 From: PabloJLZaldivar Date: Wed, 28 May 2025 10:12:07 +0200 Subject: [PATCH 1/8] add: first draft --- src/content/guides/dependency_firewall.mdx | 117 +++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 src/content/guides/dependency_firewall.mdx diff --git a/src/content/guides/dependency_firewall.mdx b/src/content/guides/dependency_firewall.mdx new file mode 100644 index 00000000..fc6617d5 --- /dev/null +++ b/src/content/guides/dependency_firewall.mdx @@ -0,0 +1,117 @@ +# DOCS: Guide: Building a dependency firewall + + +/* GOALs + +Super important to: +- keep it simple +- relate to the product features, strenghs, where do we do it better? +- add examples to each topic!! clarity. +- try to make it as much hands-on as possible + +*/ + + + + +Highlight key cloudsmith functionality. including; security scanning, deny policies, block-until-scanned, vulnerability policies + +/* INTRO / PROBLEM STATEMENT + + Why/Purpose +1. set the context for the problem, what things can happen when you don't have a dependency firewall? +2. Define a clear list of negative consequences. +*/ + +## Intro: _The Hidden Risks in Your Software Supply Chain: Why Dependency Control is No Longer Optional_ + +In today's fast-paced development landscape, the ability to leverage open-source and third-party packages is a cornerstone of rapid innovation and efficiency. Teams can assemble sophisticated applications at unprecedented speeds, standing on the shoulders of a global community of developers. However, this reliance on external code introduces a complex and often underestimated set of risks. + +Imagine a bustling construction site where materials arrive from countless suppliers, each uninspected. While this might accelerate the initial building phase, it also dramatically increases the chances of incorporating substandard, insecure, or even dangerously flawed components. Similarly, software development teams frequently pull in dozens, if not hundreds, of external dependencies without rigorous scrutiny. This can unknowingly expose their organizations to a barrage of potential problems: crippling security vulnerabilities hidden within a transitive dependency, restrictive licensing terms that create legal nightmares, or deprecated packages that lead to operational instability and ballooning maintenance costs. + +The pressure to deliver quickly can often overshadow the critical need for due diligence, leaving companies vulnerable. As software supply chain attacks become increasingly sophisticated and common, and as regulatory landscapes tighten, the laissez-faire approach to dependency management is no longer sustainable. Businesses are now grappling with the urgent need to gain visibility and control over what enters their development pipelines, paving the way for solutions designed to safeguard their software and their reputation. + +/* SUGGEST OVERVIEW OF SOLUTION + +3. Stablish ground for a solution, how we can avoid this with Cloudsmith and other benefits. +*/ + +If this sounds familiar to you, keep reading. In this guide we'll cover how you can build a dependency firawall using Cloudsmith. + + + + +4. explanation of what a dependency firewall is: + Dependency Firewall consists of a set of features that allow you to exercise and implement controls over what packages can be consumed by developers and build processes. + +5. why it's important to implement, link back to the pain points mentioned in #1. + + +## Index + + +## Who's this guide for? + +If you use or craft software, this guide is for you. +No matter if you are a Cloudsmith customer or not, this guide has been created with a vendor-neutral approach that will help you understand the basics of setting up your own dependency firewall and understand why this is important for you. + + + +## how / guide + +- step-by-step guide to configuring (2-3 pages max) + + +Steps + + +The Dependency Firewall is composed of the following features: + +1. single source of truth (all formats) + 1.1. Observability and control + 1.2. Enforcement, more on point 3 & 4. + +2. Upstream proxy and caching + 2.1. dependency caching: once they've cached the dependency the first time, they will always get served the same one. This is not guaranteed in a public repo. Why? they can manipulate the versioning by deleting and reuploading on a public repo... unless you store the checksum or signing info - there's no guarantee when you download thor 1.2.3 from pypi you'll get the same one you did a month ago. + +3. Vulnerability Scanning and Policies +4. License Scanning and Policies +5. Package Deny Rules +6. Package Quarantine + + + +Ensure your teams are only pulling from Cloudsmith - which means setting up your teams and pipelines to point at Cloudsmith + +Connect Cloudsmith to upstream registries + +Bonus step: Create a policy (Licence policy, vulnerability policy) + +Bonus step: Activate "block until scanned" + + + + + +what are the features that allow you to build the firewall + + +what are the (different) approaches you could use to implement the firewall & pros/cons +- promotion workflow +- strict dependency blocking + + + +@alan topics\ +- secure isolated plane + - + - logs + - signing verification + - + - oidc access + + + + + + From a001dcaf14c021db304a74f791ec01bedc5427ef Mon Sep 17 00:00:00 2001 From: PabloJLZaldivar Date: Thu, 29 May 2025 15:49:04 +0200 Subject: [PATCH 2/8] fix: remove TODOs --- src/content/logs-and-observability/client-logs.mdx | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/content/logs-and-observability/client-logs.mdx b/src/content/logs-and-observability/client-logs.mdx index d17d8be7..88af2e25 100644 --- a/src/content/logs-and-observability/client-logs.mdx +++ b/src/content/logs-and-observability/client-logs.mdx @@ -190,9 +190,10 @@ There are two possible reasons: Logs only contain anonymous identifiers for certain objects like packages, users, or repositories. So, if the field is empty, it's likely the repository/user/token has been deleted since the download occurred. ------- - +{/* - TODO: ask @alison about any product doc with any extra info to add about use cases and user pains solved with this. - TODO: ask about retention. @ - TODO: define what are the different types of events: cache miss events. @paddy - TODO: public API support? wait for @John +*/} + From 53f4b6a3091755d593656afa5823e73391ba364c Mon Sep 17 00:00:00 2001 From: PabloJLZaldivar Date: Mon, 9 Jun 2025 23:14:49 +0200 Subject: [PATCH 3/8] reorg --- docs/graph.html | 385 +++++++++++++++++++++ src/content/guides/dependency_firewall.mdx | 238 ++++++++++--- src/content/menu.json | 4 + 3 files changed, 586 insertions(+), 41 deletions(-) create mode 100644 docs/graph.html diff --git a/docs/graph.html b/docs/graph.html new file mode 100644 index 00000000..40f14856 --- /dev/null +++ b/docs/graph.html @@ -0,0 +1,385 @@ + + + + + + JSON Content Relationship Graph + + + + + +
+

JSON Content Relationship Graph

+
+ + +
+
+ +
+ + + + diff --git a/src/content/guides/dependency_firewall.mdx b/src/content/guides/dependency_firewall.mdx index fc6617d5..b7c295c8 100644 --- a/src/content/guides/dependency_firewall.mdx +++ b/src/content/guides/dependency_firewall.mdx @@ -1,117 +1,273 @@ # DOCS: Guide: Building a dependency firewall -/* GOALs - +{/* GOALS Super important to: - keep it simple - relate to the product features, strenghs, where do we do it better? - add examples to each topic!! clarity. -- try to make it as much hands-on as possible - -*/ - +- try to make it as much hands-on as possible +*/} Highlight key cloudsmith functionality. including; security scanning, deny policies, block-until-scanned, vulnerability policies -/* INTRO / PROBLEM STATEMENT +{/* INTRO / PROBLEM STATEMENT Why/Purpose 1. set the context for the problem, what things can happen when you don't have a dependency firewall? -2. Define a clear list of negative consequences. -*/ +2. Define a clear list of negative consequences. +*/} ## Intro: _The Hidden Risks in Your Software Supply Chain: Why Dependency Control is No Longer Optional_ -In today's fast-paced development landscape, the ability to leverage open-source and third-party packages is a cornerstone of rapid innovation and efficiency. Teams can assemble sophisticated applications at unprecedented speeds, standing on the shoulders of a global community of developers. However, this reliance on external code introduces a complex and often underestimated set of risks. +In today's fast-paced development landscape, the ability to leverage open-source and third-party packages is a key component of shipping fast. Teams can assemble sophisticated applications at unprecedented speeds, standing on the shoulders of a global community of developers. However, this reliance on external code introduces a complex and often underestimated set of risks. -Imagine a bustling construction site where materials arrive from countless suppliers, each uninspected. While this might accelerate the initial building phase, it also dramatically increases the chances of incorporating substandard, insecure, or even dangerously flawed components. Similarly, software development teams frequently pull in dozens, if not hundreds, of external dependencies without rigorous scrutiny. This can unknowingly expose their organizations to a barrage of potential problems: crippling security vulnerabilities hidden within a transitive dependency, restrictive licensing terms that create legal nightmares, or deprecated packages that lead to operational instability and ballooning maintenance costs. +Imagine a bustling construction site where materials arrive from countless suppliers, without any kind of suppervision or trazability. While this might accelerate the initial building phase, it also dramatically increases the chances of incorporating substandard, insecure, or even dangerously flawed components. Similarly, software development teams frequently pull in dozens, if not hundreds, of external dependencies without rigorous scrutiny. This can unknowingly expose their organizations to a myriad of potential problems: crippling security vulnerabilities hidden within a transitive dependency, restrictive licensing terms that create legal nightmares, or deprecated packages that lead to operational instability and ballooning maintenance costs. The pressure to deliver quickly can often overshadow the critical need for due diligence, leaving companies vulnerable. As software supply chain attacks become increasingly sophisticated and common, and as regulatory landscapes tighten, the laissez-faire approach to dependency management is no longer sustainable. Businesses are now grappling with the urgent need to gain visibility and control over what enters their development pipelines, paving the way for solutions designed to safeguard their software and their reputation. +{/* /* SUGGEST OVERVIEW OF SOLUTION 3. Stablish ground for a solution, how we can avoid this with Cloudsmith and other benefits. -*/ -If this sounds familiar to you, keep reading. In this guide we'll cover how you can build a dependency firawall using Cloudsmith. +*/} + +If this challenges sound familiar to you, keep reading. In this guide we'll cover how you can build a dependency firewall with Cloudsmith. You'll be creating a layer of protection between your systems and threats imported from public open source repositories. +A dependency Firewall consists of a set of features that allow you to exercise and implement controls over what packages can be consumed by developers and build processes. +## Who's this guide for? -4. explanation of what a dependency firewall is: - Dependency Firewall consists of a set of features that allow you to exercise and implement controls over what packages can be consumed by developers and build processes. +If you use or craft software, this guide is for you. This content might also be helpful for Security and Operation teams. +No matter if you are a Cloudsmith customer or not, you can [sign-up for a trial account]() and follow this guide to understand the basics of setting up your own dependency firewall. -5. why it's important to implement, link back to the pain points mentioned in #1. +## Building a Dependency Firewall +In the next section we'll show a step by step guide with different actions you can take to build your own dependency firewall with Cloudsmith. -## Index +Here's an overview of the different areas we'll cover: +1. Control of Dependencies +2. Upstream Proxying and Caching +3. Artifact Advisories +4. Policies +5. +--- -## Who's this guide for? +### 1. Control of dependencies + +For most organizations, there's a common ausence of visibility over OSS software used in most of their Software Development Life Cicle (SDLC). Everything is allowed to ship new features in time. This leads to a point in which it is almost impossible to track which packages have been running in your infra, with the consequent increase in risk. The first step to take control is to increase visibility: you can't control what you don't see. + +Cloudsmith is your single pane of glass for all kind of artifacts. With an extensive [support of 30 different package formats](), +Cloudsmith provides an easy to manage but yet advanced platform that support all the native tooling your developers use. + +Let's [create a repository](). Browse to your Cloudsmith workspace and click on **+ New Repository**. Type a (for example: `dev-env`, select a region (default to `Dublin`), and click on **+ Create Repository**. Your new repo has been created! + +Depending on your use cases or how you want to distribute your software, you have different visibility options for your repositories: Public, Private, and OSS. By default, new repositories are private. You can browse to [Settings](https://app.cloudsmith.com///settings) and click on **Make repository public**. Private repositories can be accessed via Entitlement Tokens. For this example, let's make it public. + +Now we'll get some hands-on practice pushing and pulling artifacts from this repo. But first, let's define some variables in our terminal to reuse during this demo guide: + +```bash +export CLOUDSMITH_USERNAME= # Available in user settings +export CLOUDSMITH_API_TOKEN= # Available in user settings +export CLOUDSMITH_WORKSPACE_NAME= +export CLOUDSMITH_REPOSITORY= +export CLOUDSMITH_REPOSITORY_IS_PRIVATE=yes +``` + +You can use this repo to upload any kind of asset: from _Python_ or _Golang_ packages to _Docker containers_. For example, let's upload a _Helm chart_: + +``` +# add and update a helm repo + download a sample chart +helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx +helm repo update +helm pull ingress-nginx/ingress-nginx + +# list the chart +ls ingress-nginx-4.12.3.tgz + +# Login to your OCI-compliant Helm repository in Cloudsmith +helm registry login helm.oci.cloudsmith.io -u $CLOUDSMITH_USERNAME -P $API_TOKEN + +# Push the chart +helm push ingress-nginx-4.12.3.tgz oci://helm.oci.cloudsmith.io/$CLOUDSMITH_API_TOKEN/$REPO_NAME +``` + +Once completed, browse to [your repository](https://app.cloudsmith.com//) and observe the new package. + +πŸ“˜ Cloudsmith provides full controls to define who can view or make changes to your repos. Learn more about it [here](). + +Now, you can upload any other artifact you might want to test. Explore all the formats supported, and play with those more familiar to you. Alternatively, use this project https://github.com/cloudsmith-io/cloudsmith-examples to populate your new repository with some more examples for this demo: + +```bash +git clone https://github.com/cloudsmith-io/cloudsmith-examples.git +cd cloudsmith-examples +./bin/run-examples +``` + +Once it's running, browse again to the repository and see the first packages being uploaded: Maven, Debian, npm, Rust, and other different assets are being created in your repo. Cloudsmith is your control plane for universal artifact management. Al different formats supported in one location. + +Now that we pushed some artifacts to the repo, let's try to pull some of them to our local machine.Cloudsmith support all the native tooling you use for your artifacts. For each of them, contextual instructions are provided within the product. Also, instructions to learn how to configure your CLI tools or projects to pull images directly from Cloudsmith. + + +πŸ“˜ An important part of building a Dependency Firewall is blocking any source of artifacts that we don't allow within our org. There are different approaches to tackle this: +- **Network Controls**: Implement firewall rules, proxy configurations, and egress filtering to block direct access to external public repositories like Docker Hub, Maven Central, PyPI, or public Helm chart repositories. Allow only traffic to your internal artifact repository. +- **Configuration management**: For example, configure the Docker daemon on developer machines and build servers to use your internal registry as a mirror. This way, if an image is requested, Docker will first check your internal registry. If not found, it will still try the public registry unless you block it at the network level. + +For example: + +```json +{ + "registry-mirrors": ["https://my-internal-registry.company.com"] +} +``` + +Reach out to our [Support team]() to learn more about all of the alternatives we provide. + + +Cloudsmith provides a CLI and support for all major native tooling for your packages. It also includes instructions to configure your new repository as the only source of artifacts for your developers. As we'll see later, Cloudsmith allows you to enforce which software is allowed within your organization. + +{/* Ensure your teams are only pulling from Cloudsmith - which means setting up your teams and pipelines to point at Cloudsmith. + Talk about teams, accounts, services, workspace members. */} -If you use or craft software, this guide is for you. -No matter if you are a Cloudsmith customer or not, this guide has been created with a vendor-neutral approach that will help you understand the basics of setting up your own dependency firewall and understand why this is important for you. +#### Retention Rules +#### Actively blocking external no-compliant repositories +#### Observability and Logging -## how / guide +As part of the visibility features, Cloudsmith provides different observability functions to understand how dependencies are being used within your organization. Browse to your repo and click Logs. -- step-by-step guide to configuring (2-3 pages max) +The Client Logs are presented. Here you can see an overview of all of the different artifact files downloaded within your organization. This will give you insights about when, how, and by whom your packages are being used. +Most importantly, Cloudsmith provide an Audit logs panel to track the actions of every single organizational member. Every package that is uploaded or deleted, entitlement tokens creation, logings, creation of new upstreams and every single action within your repository are registered so you can have a full audit of what happened. -Steps +Cloudsmith is the **single source of truth** for all your package formats. +### 2. Upstream Proxying and Caching -The Dependency Firewall is composed of the following features: +There are no risks in empty repositories, but there's also no use from it for developers. What if you could merge all the flexibility from public upstreams with the control of Cloudsmith? -1. single source of truth (all formats) - 1.1. Observability and control - 1.2. Enforcement, more on point 3 & 4. - -2. Upstream proxy and caching - 2.1. dependency caching: once they've cached the dependency the first time, they will always get served the same one. This is not guaranteed in a public repo. Why? they can manipulate the versioning by deleting and reuploading on a public repo... unless you store the checksum or signing info - there's no guarantee when you download thor 1.2.3 from pypi you'll get the same one you did a month ago. +Learn how to configure different upstreams to proxy and cache the sources of software you already use within Cloudsmith. +To connect your repository to different Upstreams, you only need to enable each of them. Browse to your repository and click in **Upstreams**. +Click in Upstreams and use the quick configure wizard. Just click on PyPi Official and your upstream will be configured. -3. Vulnerability Scanning and Policies -4. License Scanning and Policies -5. Package Deny Rules -6. Package Quarantine +See the upstream configured, the status icon provides information about the progress: "Upstream is caching proxied packages to this repository". +Test it using `numpy`: +``` +pip install numpy --index-url https://dl.cloudsmith.io/ig64XkSDAqedAZWL/demo-docs/awesome-repo/python/simple/ +``` -Ensure your teams are only pulling from Cloudsmith - which means setting up your teams and pipelines to point at Cloudsmith +Reliability of Public Repositories: Public repositories don’t provide any guarantees that a package that was there yesterday, and that you now depend on, will still be there today. The repositories themselves also don’t offer SLAs and may suffer downtime. -Connect Cloudsmith to upstream registries +Positive side-effect: dependency caching. once they've cached the dependency the first time, they will always get served the same one. This is not guaranteed in a public repo. Why? they can manipulate the versioning by deleting and reuploading on a public repo... unless you store the checksum or signing info - there's no guarantee when you download thor 1.2.3 from pypi you'll get the same one you did a month ago. -Bonus step: Create a policy (Licence policy, vulnerability policy) +Adding to this, you'll get another benefit from storing your dependencies in Cloudsmith. You are safe from outages. If the upstream registry is down, you'll still have access to your assets via Cloudsmith registries. -Bonus step: Activate "block until scanned" +### 3. Artifact Advisories +Advisories, what are they? -what are the features that allow you to build the firewall +#### 3.1. Malware +#### 3.2. Vulnerabilities + + +Recurrent scans. New vulnerabilities are discovered every single day. + +#### 3.1. Malware + +buscar ejemplo de imagen con malware. + + + +### 4. Policies + +EPM +Improving your security posture is a long-run effort that goes beyond visibility and control: it requires stablishing and enforcing policies across your whole organization. + +There's a multitude of security solutions that are great providing new findings, but fall short taking action. + + + +### 5. + +------------ + +Defense in deepth: multiple layers, onion. Not only checking incoming vulnerabilities, but also the result of our pipelines. Talk about GH integration. + + + + + +4. Licenses + +License Compliance Risks: Open source software can contain a dizzying variety of licenses. Inadvertently introducing new types of OSS licensing can create a threat to legal compliance and alter the legal status of your software, exposing you to litigation. + +5. Package Deny Rules +6. Package Quarantine +7. Block Until Scanned + +8. Observability and Logging: esto igual mejor meterlo en punto 1. + +Talk here about the different features available: +- client logs: observe how packages are being consumed +- package logs: +- audit logs: + +features here. + +No tengo nada sobre tema entitlement tokens, pero podria ser parte de la solucion. No solo de entrada sino salida. + what are the (different) approaches you could use to implement the firewall & pros/cons - promotion workflow - strict dependency blocking +aqui estaria bien comparar cada una de las alternativas y ver como se comportan la una con la otra. pros y contras de las mismas. + + +{/* @alan topics\ - secure isolated plane - - - logs - signing verification - - - oidc access + - oidc access + */} + +How it works: +Early Vulnerability Detection: +The dependency firewall identifies potential issues like security vulnerabilities and license violations at the dependency declaration stage, before they are added to your project. +Blocking Malicious or Risky Packages: +It can block the download of malicious or unsafe open-source packages, preventing them from being integrated into your codebase. +Blocking Vulnerable Builds: +It can prevent the creation of builds that contain high-severity CVEs, operational risks, or other security threats. +Integration with SDLC: +The Cloudsmith Security features are integrated into various SDLC stages, including artifact repositories, CI/CD pipelines, and even IDEs. +Benefits of using the dependency firewall: +Improved Security: +By preventing the entry of vulnerabilities, you reduce the risk of attacks and security incidents. +Enhanced Compliance: +The feature helps ensure compliance with licensing requirements and other regulatory standards. +Reduced Risk: +By blocking builds with high-severity vulnerabilities, you mitigate the risk of introducing security weaknesses into your applications. +Simplified Management: +The Cloudsmith solutions simplify the management of dependencies and make it easier to maintain a secure software supply chain. diff --git a/src/content/menu.json b/src/content/menu.json index d8b35c62..f7dd6b5b 100644 --- a/src/content/menu.json +++ b/src/content/menu.json @@ -732,6 +732,10 @@ "title": "Getting started", "path": "/guides/getting-started" }, + { + "title": "Dependency Firewall with Cloudsmith", + "path": "/guides/dependency_firewall" + }, { "title": "Test Guide", "path": "/guides/test-guide" From 8797cd26e74603c4afb9e771496563701b78429b Mon Sep 17 00:00:00 2001 From: PabloJLZaldivar Date: Fri, 13 Jun 2025 16:11:07 +0200 Subject: [PATCH 4/8] - --- src/content/guides/dependency_firewall.mdx | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/src/content/guides/dependency_firewall.mdx b/src/content/guides/dependency_firewall.mdx index b7c295c8..8f3a8f26 100644 --- a/src/content/guides/dependency_firewall.mdx +++ b/src/content/guides/dependency_firewall.mdx @@ -2,6 +2,8 @@ {/* GOALS +Highlight key cloudsmith functionality. including; security scanning, deny policies, block-until-scanned, vulnerability policies + Super important to: - keep it simple - relate to the product features, strenghs, where do we do it better? @@ -11,7 +13,7 @@ Super important to: -Highlight key cloudsmith functionality. including; security scanning, deny policies, block-until-scanned, vulnerability policies + {/* INTRO / PROBLEM STATEMENT @@ -62,6 +64,8 @@ Here's an overview of the different areas we'll cover: For most organizations, there's a common ausence of visibility over OSS software used in most of their Software Development Life Cicle (SDLC). Everything is allowed to ship new features in time. This leads to a point in which it is almost impossible to track which packages have been running in your infra, with the consequent increase in risk. The first step to take control is to increase visibility: you can't control what you don't see. +#### 1.1. Single source of truth for your all your artifacts + Cloudsmith is your single pane of glass for all kind of artifacts. With an extensive [support of 30 different package formats](), Cloudsmith provides an easy to manage but yet advanced platform that support all the native tooling your developers use. @@ -77,11 +81,22 @@ export CLOUDSMITH_API_TOKEN= # Available in user settings export CLOUDSMITH_WORKSPACE_NAME= export CLOUDSMITH_REPOSITORY= export CLOUDSMITH_REPOSITORY_IS_PRIVATE=yes + +#download and setup cloudsmith-cli + ``` -You can use this repo to upload any kind of asset: from _Python_ or _Golang_ packages to _Docker containers_. For example, let's upload a _Helm chart_: +You can use this repo to upload any kind of asset: from _Python_ or _Golang_ packages to _Docker containers_. Let's see a couple of examples. With python (pip3 required): + +```bash +pip3 download adorable +cloudsmith push python demo-docs/awesome-repo adorable-0.1.5-py3-none-any.whl ``` + +Or, for example, let's upload a _Helm chart_: + +```bash # add and update a helm repo + download a sample chart helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update @@ -129,7 +144,6 @@ For example: Reach out to our [Support team]() to learn more about all of the alternatives we provide. -Cloudsmith provides a CLI and support for all major native tooling for your packages. It also includes instructions to configure your new repository as the only source of artifacts for your developers. As we'll see later, Cloudsmith allows you to enforce which software is allowed within your organization. {/* Ensure your teams are only pulling from Cloudsmith - which means setting up your teams and pipelines to point at Cloudsmith. Talk about teams, accounts, services, workspace members. */} From f5ba7b60f519c94a7e5ceccc4925138971c32f5b Mon Sep 17 00:00:00 2001 From: PabloJLZaldivar Date: Wed, 18 Jun 2025 10:37:10 +0200 Subject: [PATCH 5/8] - --- src/content/guides/dependency_firewall.mdx | 30 ++++++++++++++++------ 1 file changed, 22 insertions(+), 8 deletions(-) diff --git a/src/content/guides/dependency_firewall.mdx b/src/content/guides/dependency_firewall.mdx index 8f3a8f26..0be853ec 100644 --- a/src/content/guides/dependency_firewall.mdx +++ b/src/content/guides/dependency_firewall.mdx @@ -2,7 +2,11 @@ {/* GOALS -Highlight key cloudsmith functionality. including; security scanning, deny policies, block-until-scanned, vulnerability policies +Highlight key cloudsmith functionality. including; +- security scanning, +- deny policies, +- block-until-scanned, +- vulnerability policies Super important to: - keep it simple @@ -11,9 +15,13 @@ Super important to: - try to make it as much hands-on as possible */} +{/* +OPEN QUSTIONS +- what about transitive dependencies? can we catch it all? If not, which alternatives we suggest to customers? +*/} {/* INTRO / PROBLEM STATEMENT @@ -44,8 +52,8 @@ A dependency Firewall consists of a set of features that allow you to exercise a ## Who's this guide for? -If you use or craft software, this guide is for you. This content might also be helpful for Security and Operation teams. -No matter if you are a Cloudsmith customer or not, you can [sign-up for a trial account]() and follow this guide to understand the basics of setting up your own dependency firewall. +If you develop or use 3rd party software, this guide is for you. This content might also be helpful for Security and DevOps teams. +No matter if you are a Cloudsmith customer or not, you can [sign-up for a trial account](https://app.cloudsmith.com/signup?next=%2F) and follow this guide to understand the basics of setting up your own dependency firewall. ## Building a Dependency Firewall @@ -56,7 +64,11 @@ Here's an overview of the different areas we'll cover: 2. Upstream Proxying and Caching 3. Artifact Advisories 4. Policies -5. + 4.1. Vulnerability Policies + 4.2. Package Deny Policies + 4.3. Block Until Scanned + 4.4. Licenses + --- @@ -66,10 +78,12 @@ For most organizations, there's a common ausence of visibility over OSS software #### 1.1. Single source of truth for your all your artifacts +{/* create multiple registries for the package promotion strategy */} + Cloudsmith is your single pane of glass for all kind of artifacts. With an extensive [support of 30 different package formats](), Cloudsmith provides an easy to manage but yet advanced platform that support all the native tooling your developers use. -Let's [create a repository](). Browse to your Cloudsmith workspace and click on **+ New Repository**. Type a (for example: `dev-env`, select a region (default to `Dublin`), and click on **+ Create Repository**. Your new repo has been created! +Let's [create a repository](https://docs.cloudsmith.com/repositories/create-a-repository). Browse to your Cloudsmith workspace and click on **+ New Repository**. Type a (for example: `dev-env`, select a region (default to `Dublin`), and click on **+ Create Repository**. Your new repo has been created! Depending on your use cases or how you want to distribute your software, you have different visibility options for your repositories: Public, Private, and OSS. By default, new repositories are private. You can browse to [Settings](https://app.cloudsmith.com///settings) and click on **Make repository public**. Private repositories can be accessed via Entitlement Tokens. For this example, let's make it public. @@ -187,7 +201,6 @@ Adding to this, you'll get another benefit from storing your dependencies in Clo ### 3. Artifact Advisories - Advisories, what are they? @@ -216,7 +229,7 @@ There's a multitude of security solutions that are great providing new findings, ------------ -Defense in deepth: multiple layers, onion. Not only checking incoming vulnerabilities, but also the result of our pipelines. Talk about GH integration. +Defense in depth: multiple layers, onion. Not only checking incoming vulnerabilities, but also the result of our pipelines. Talk about GH integration. @@ -245,8 +258,9 @@ No tengo nada sobre tema entitlement tokens, pero podria ser parte de la solucio what are the (different) approaches you could use to implement the firewall & pros/cons - promotion workflow +{/* help required here */} - strict dependency blocking - +{/* this workflow is clear */} aqui estaria bien comparar cada una de las alternativas y ver como se comportan la una con la otra. pros y contras de las mismas. From 5509dc89517e4fddd684ddc68864ae60f896ebba Mon Sep 17 00:00:00 2001 From: PabloJLZaldivar Date: Tue, 24 Jun 2025 09:56:46 +0200 Subject: [PATCH 6/8] - --- src/content/guides/dependency_firewall.mdx | 265 +++++++++++---------- 1 file changed, 139 insertions(+), 126 deletions(-) diff --git a/src/content/guides/dependency_firewall.mdx b/src/content/guides/dependency_firewall.mdx index 0be853ec..45810774 100644 --- a/src/content/guides/dependency_firewall.mdx +++ b/src/content/guides/dependency_firewall.mdx @@ -38,17 +38,7 @@ Imagine a bustling construction site where materials arrive from countless suppl The pressure to deliver quickly can often overshadow the critical need for due diligence, leaving companies vulnerable. As software supply chain attacks become increasingly sophisticated and common, and as regulatory landscapes tighten, the laissez-faire approach to dependency management is no longer sustainable. Businesses are now grappling with the urgent need to gain visibility and control over what enters their development pipelines, paving the way for solutions designed to safeguard their software and their reputation. -{/* -/* SUGGEST OVERVIEW OF SOLUTION - -3. Stablish ground for a solution, how we can avoid this with Cloudsmith and other benefits. - -*/} - -If this challenges sound familiar to you, keep reading. In this guide we'll cover how you can build a dependency firewall with Cloudsmith. You'll be creating a layer of protection between your systems and threats imported from public open source repositories. - -A dependency Firewall consists of a set of features that allow you to exercise and implement controls over what packages can be consumed by developers and build processes. - +If this challenges resonate in you, keep reading. In this guide, we'll cover how you can build a **dependency firewall** with Cloudsmith. A dependency Firewall consists of a set of features that allow you to exercise and implement controls over what packages can be consumed by developers and build processes. In the next sections, you'll be creating a layer of protection between your systems and threats imported from public open source repositories. ## Who's this guide for? @@ -57,37 +47,65 @@ No matter if you are a Cloudsmith customer or not, you can [sign-up for a trial ## Building a Dependency Firewall -In the next section we'll show a step by step guide with different actions you can take to build your own dependency firewall with Cloudsmith. - Here's an overview of the different areas we'll cover: 1. Control of Dependencies 2. Upstream Proxying and Caching 3. Artifact Advisories + 3.1. Vulnerability Policies + 3.2. Package Deny Policies + 3.3. Block Until Scanned + 3.4. Licenses 4. Policies - 4.1. Vulnerability Policies - 4.2. Package Deny Policies - 4.3. Block Until Scanned - 4.4. Licenses + --- ### 1. Control of dependencies -For most organizations, there's a common ausence of visibility over OSS software used in most of their Software Development Life Cicle (SDLC). Everything is allowed to ship new features in time. This leads to a point in which it is almost impossible to track which packages have been running in your infra, with the consequent increase in risk. The first step to take control is to increase visibility: you can't control what you don't see. +For some organizations, there's a common ausence of visibility over OSS software usage in any of the stages of their Software Development Life Cycle (SDLC). Everything is allowed to ship new features fast, leading to a point in which it is almost impossible to track which packages have been running, with the consequent increase in risk. The first step to take control is to increase visibility: you can't control what you don't see. + +Let's start cloning a sample project: + +``` +git clone +cd +code . +``` + +It contains a microservices app composed of a node frontend, python backend, and a mariadb database, all of them prepared to be deployed in a Kubernetes cluster. + +Although there two sample apps together don't sum up more than 100 lines of code, the number of dependencies required to execute them is surprising. For example, browse to the frontend app directory and use `npx howfat` to list information about dependencies in use: + +```bash +cd frontend +npx howfat -r tree +``` + +This tool provides a glance of the number of dependencies, files, and total size of a project including it's dependencies and transitive dependencies. In this case, for an app with no more than 25 lines of code, there's a total of 88 different 3rd party additions to the codebase. + +Without any kind of supply chain management solution, tracking the usage of dependencies across different teams, stacks, and environments might be a challenging endeavour. In the next step we'll see how to use Cloudsmith to observe and control the software you run. #### 1.1. Single source of truth for your all your artifacts -{/* create multiple registries for the package promotion strategy */} +Cloudsmith is your single pane of glass for all kind of artifacts. With an extensive [support of 30 different package formats](https://docs.cloudsmith.com/formats), Cloudsmith provides an easy to manage but yet advanced platform that support all the native tooling your developers use. + +Let's [create a repository](https://docs.cloudsmith.com/repositories/create-a-repository) for our microservices stack: +1. Browse to your Cloudsmith workspace and click on **+ New Repository**. +2. Type a name (for example: `dev-env`), +3. select a region (default to `Dublin`), +4. and click on **+ Create Repository**. -Cloudsmith is your single pane of glass for all kind of artifacts. With an extensive [support of 30 different package formats](), -Cloudsmith provides an easy to manage but yet advanced platform that support all the native tooling your developers use. +Our new repo is created! -Let's [create a repository](https://docs.cloudsmith.com/repositories/create-a-repository). Browse to your Cloudsmith workspace and click on **+ New Repository**. Type a (for example: `dev-env`, select a region (default to `Dublin`), and click on **+ Create Repository**. Your new repo has been created! +Depending on your use case or how you want to distribute your software, you have different visibility options for your repositories: +- Public +- Private +- or Open Source Software OSS. -Depending on your use cases or how you want to distribute your software, you have different visibility options for your repositories: Public, Private, and OSS. By default, new repositories are private. You can browse to [Settings](https://app.cloudsmith.com///settings) and click on **Make repository public**. Private repositories can be accessed via Entitlement Tokens. For this example, let's make it public. +By default, new repositories are private. You can browse to the Settings in your repository ([https://app.cloudsmith.com///settings](https://app.cloudsmith.com///settings)) and select **Make repository public**. Private repositories can be accessed via Entitlement Tokens, to have a higher level of control over who access your software. But, for this example, let's make it public. -Now we'll get some hands-on practice pushing and pulling artifacts from this repo. But first, let's define some variables in our terminal to reuse during this demo guide: +{/* Now we'll get some hands-on practice pushing and pulling artifacts from this repo. But first, let's define some variables in our terminal to reuse during this demo guide: ```bash export CLOUDSMITH_USERNAME= # Available in user settings @@ -98,49 +116,102 @@ export CLOUDSMITH_REPOSITORY_IS_PRIVATE=yes #download and setup cloudsmith-cli -``` +``` */} -You can use this repo to upload any kind of asset: from _Python_ or _Golang_ packages to _Docker containers_. Let's see a couple of examples. With python (pip3 required): +Now that our repository is created, let's configure our native tooling to push and pull packages directly from our Cloudsmith repository. +We can also use the cloudsmith CLI to manage artifacts from different formats, or perform actions against any of our repositories. + +{/* TODO, try to automate this via API to hide a bit what we are doing and avoid going to the old UI */} +πŸ“˜ npm and pypi redirects +To continue with this guide, browse to your repo settings in the old UI ([https://cloudsmith.io/~/repos//settings/](https://cloudsmith.io/~/repos//settings/)) and disable the next two options: +- Proxy Python Packages? +- Proxy Npm Packages? + + +{/* TODO: better use the file config instead of adding the registry option on every command */} +For our NodeJS modules, we can use `npm` and just point it to: `https://npm.cloudsmith.io/WORKSPACE/REPOSITORY/` (learn more about the different configuration options in the general [NodeJS docs](https://help.cloudsmith.io/docs/npm-registry)). For example, we can install all required dependencies for this project using `npn`: ```bash -pip3 download adorable -cloudsmith push python demo-docs/awesome-repo adorable-0.1.5-py3-none-any.whl +npm install --registry https://npm.cloudsmith.io/demo-docs/no-upstream-npm --loglevel verbose +``` +```logs +npm verbose pkgid axios@^1.4.0 +npm error code E404 +npm error 404 Not Found - GET https://npm.cloudsmith.io/demo-docs/no-upstream-npm/axios - Not found. ``` -Or, for example, let's upload a _Helm chart_: +The package is not found. Let's try with the Python app, we can run: ```bash -# add and update a helm repo + download a sample chart -helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx -helm repo update -helm pull ingress-nginx/ingress-nginx +cd ../backend +pip install --index-url https://dl.cloudsmith.io/public/demo-docs/no-upstream-npm/python/simple/ -r requirements.txt -vvv; +``` -# list the chart -ls ingress-nginx-4.12.3.tgz +We get a similar error: -# Login to your OCI-compliant Helm repository in Cloudsmith -helm registry login helm.oci.cloudsmith.io -u $CLOUDSMITH_USERNAME -P $API_TOKEN +```logs +Could not fetch URL https://dl.cloudsmith.io/public/demo-docs/no-upstream-npm/python/simple/flask/: 404 Client Error: Not Found for url: https://dl.cloudsmith.io/public/demo-docs/no-upstream-npm/python/simple/flask/ - skipping +Skipping link: not a file: https://dl.cloudsmith.io/public/demo-docs/no-upstream-npm/python/simple/flask/ +Given no hashes to check 0 links for project 'flask': discarding no candidates +ERROR: Could not find a version that satisfies the requirement Flask==2.0.1 (from versions: none) +``` + +This is good! What is going on? We have not configured any upstream for our repository, hence those dependencies from https://www.npmjs.com/ and https://www.pypi.com/ are not available to use them. In the next section we'll learn about Upstreams and how to [configure](https://docs.cloudsmith.com/tbc/upstream-proxying-and-caching) them. + +### 2. Upstream Proxying and Caching + +Upstreams refer to the original source or maintainer of a piece of software, code, or a package. This can be public registries or private repositories from any vendor. With Cloudsmith, you can proxy them all to control de software your developers consume. + +Having a repository without access to public package sources might be a valid use case, as we'll explore later (see Package Promotion strategies). But for most cases, having access to popular upstreams like Pypi or npm is a common choice for any repository. With Cloudsmith, you can have all the power and flexibility of open source packages in public upstreams without sacrificing artifact control and visibility. + +#### Enabling Upstreams within your repository -# Push the chart -helm push ingress-nginx-4.12.3.tgz oci://helm.oci.cloudsmith.io/$CLOUDSMITH_API_TOKEN/$REPO_NAME +To connect your repository to different Upstreams, you only need to enable each of them. Browse to your repository and click in **Upstreams** tab. Then, use the quick configure wizard and just click in the Upstreams required for this project: +- NPMJS.com +- Pypi Official + +See the upstream configured, the status icon provides information about the progress: "Upstream is caching proxied packages to this repository". Once enabled, both are available to use. Retry the previous commands: + +```bash +cd ../frontend +npm install --registry https://npm.cloudsmith.io/demo-docs/no-upstream-npm +cd ../backend +pip install --index-url https://dl.cloudsmith.io/public/demo-docs/no-upstream-npm/python/simple/ -r requirements.txt ``` -Once completed, browse to [your repository](https://app.cloudsmith.com//) and observe the new package. +Now it worked. Cloudsmith found all the artifacts required from your project. Browse to your repository overview page and take a look at the list of dependencies used. + + +πŸ“˜ With Cloudsmith, you can't only proxy public repositories, but also cache their assets. Public repositories don't provide any guarantees that a package that was available today will still be there tomorrow. The repositories themselves also don't offer SLAs and may suffer downtime. Another positive side-effect of dependecy caching is that once we have cached the dependency, it will always be the same one. This is not guaranteed in a public repo, as they can manipulate the versioning by deleting and reuploading any of the packages available. + +Adding to this, you'll get another benefit from storing your dependencies in Cloudsmith. You are safe from outages. If the upstream registry is down, you'll still have access to your assets via Cloudsmith registries. + +--- + +We can also use this repo to upload any kind of asset: from _NodeJS_, to Python_, _Golang_, or_Docker containers_. +Let's see a couple of examples. With python (pip3 required): + +```bash +cd ../backend +pip3 download adorable +cloudsmith push python demo-docs/awesome-repo adorable-0.1.5-py3-none-any.whl +``` -πŸ“˜ Cloudsmith provides full controls to define who can view or make changes to your repos. Learn more about it [here](). +πŸ“˜ Cloudsmith provides full controls to define who can view or make changes to your repos. Learn more about permissions and entitlements [here](). -Now, you can upload any other artifact you might want to test. Explore all the formats supported, and play with those more familiar to you. Alternatively, use this project https://github.com/cloudsmith-io/cloudsmith-examples to populate your new repository with some more examples for this demo: +{/* Now, you can upload any other artifact you might want to test. Explore all the formats supported, and play with those more familiar to you. Alternatively, use this project https://github.com/cloudsmith-io/cloudsmith-examples to populate your new repository with alternative examples: ```bash git clone https://github.com/cloudsmith-io/cloudsmith-examples.git cd cloudsmith-examples ./bin/run-examples ``` - Once it's running, browse again to the repository and see the first packages being uploaded: Maven, Debian, npm, Rust, and other different assets are being created in your repo. Cloudsmith is your control plane for universal artifact management. Al different formats supported in one location. -Now that we pushed some artifacts to the repo, let's try to pull some of them to our local machine.Cloudsmith support all the native tooling you use for your artifacts. For each of them, contextual instructions are provided within the product. Also, instructions to learn how to configure your CLI tools or projects to pull images directly from Cloudsmith. +Now that we pushed some artifacts to the repo, let's try to pull some of them to our local machine. Cloudsmith support all the native tooling you use for your artifacts. For each of them, contextual instructions are provided within the product. Also, instructions to learn how to configure your CLI tools or projects to pull images directly from Cloudsmith. + +*/} πŸ“˜ An important part of building a Dependency Firewall is blocking any source of artifacts that we don't allow within our org. There are different approaches to tackle this: @@ -162,41 +233,9 @@ Reach out to our [Support team]() to learn more about all of the alternatives we {/* Ensure your teams are only pulling from Cloudsmith - which means setting up your teams and pipelines to point at Cloudsmith. Talk about teams, accounts, services, workspace members. */} -#### Retention Rules - -#### Actively blocking external no-compliant repositories - -#### Observability and Logging - -As part of the visibility features, Cloudsmith provides different observability functions to understand how dependencies are being used within your organization. Browse to your repo and click Logs. - -The Client Logs are presented. Here you can see an overview of all of the different artifact files downloaded within your organization. This will give you insights about when, how, and by whom your packages are being used. - -Most importantly, Cloudsmith provide an Audit logs panel to track the actions of every single organizational member. Every package that is uploaded or deleted, entitlement tokens creation, logings, creation of new upstreams and every single action within your repository are registered so you can have a full audit of what happened. - -Cloudsmith is the **single source of truth** for all your package formats. - -### 2. Upstream Proxying and Caching - -There are no risks in empty repositories, but there's also no use from it for developers. What if you could merge all the flexibility from public upstreams with the control of Cloudsmith? - -Learn how to configure different upstreams to proxy and cache the sources of software you already use within Cloudsmith. -To connect your repository to different Upstreams, you only need to enable each of them. Browse to your repository and click in **Upstreams**. -Click in Upstreams and use the quick configure wizard. Just click on PyPi Official and your upstream will be configured. - -See the upstream configured, the status icon provides information about the progress: "Upstream is caching proxied packages to this repository". - -Test it using `numpy`: +{/* Add example to push to the repo the app we just build, native + docker */} -``` -pip install numpy --index-url https://dl.cloudsmith.io/ig64XkSDAqedAZWL/demo-docs/awesome-repo/python/simple/ -``` - -Reliability of Public Repositories: Public repositories don’t provide any guarantees that a package that was there yesterday, and that you now depend on, will still be there today. The repositories themselves also don’t offer SLAs and may suffer downtime. - -Positive side-effect: dependency caching. once they've cached the dependency the first time, they will always get served the same one. This is not guaranteed in a public repo. Why? they can manipulate the versioning by deleting and reuploading on a public repo... unless you store the checksum or signing info - there's no guarantee when you download thor 1.2.3 from pypi you'll get the same one you did a month ago. - -Adding to this, you'll get another benefit from storing your dependencies in Cloudsmith. You are safe from outages. If the upstream registry is down, you'll still have access to your assets via Cloudsmith registries. +Now, we not only block dependencies from other external repositories, but also have full visibility about all the dependencies being used by our applications. What about enforcing more advances criteria to guarantee that no known vulnerbale software is used? ### 3. Artifact Advisories @@ -225,77 +264,51 @@ There's a multitude of security solutions that are great providing new findings, -### 5. - ------------- - -Defense in depth: multiple layers, onion. Not only checking incoming vulnerabilities, but also the result of our pipelines. Talk about GH integration. +### 5. Bonus tracks +#### Actively blocking external no-compliant repositories +5. Package Deny Rules +6. Package Quarantine +7. Block Until Scanned +#### Observability and Logging +As part of the visibility features, Cloudsmith provides different observability functions to understand how dependencies are being used within your organization. Browse to your repo and click Logs. -4. Licenses +The Client Logs are presented. Here you can see an overview of all of the different artifact files downloaded within your organization. This will give you insights about when, how, and by whom your packages are being used. -License Compliance Risks: Open source software can contain a dizzying variety of licenses. Inadvertently introducing new types of OSS licensing can create a threat to legal compliance and alter the legal status of your software, exposing you to litigation. +Most importantly, Cloudsmith provide an Audit logs panel to track the actions of every single organizational member. Every package that is uploaded or deleted, entitlement tokens creation, logings, creation of new upstreams and every single action within your repository are registered so you can have a full audit of what happened. -5. Package Deny Rules -6. Package Quarantine -7. Block Until Scanned +Cloudsmith is the **single source of truth** for all your package formats. -8. Observability and Logging: esto igual mejor meterlo en punto 1. +Observability and Logging: Talk here about the different features available: - client logs: observe how packages are being consumed - package logs: - audit logs: -features here. - -No tengo nada sobre tema entitlement tokens, pero podria ser parte de la solucion. No solo de entrada sino salida. - +{/* DON'T INCLUDE #### Retention Rules */} +------------ -what are the (different) approaches you could use to implement the firewall & pros/cons -- promotion workflow -{/* help required here */} -- strict dependency blocking -{/* this workflow is clear */} -aqui estaria bien comparar cada una de las alternativas y ver como se comportan la una con la otra. pros y contras de las mismas. - +Defense in depth: multiple layers, onion. Not only checking incoming vulnerabilities, but also the result of our pipelines. Talk about GH integration. -{/* -@alan topics\ -- secure isolated plane - - - - signing verification - - - - oidc access - */} +4. Licenses +License Compliance Risks: Open source software can contain a dizzying variety of licenses. Inadvertently introducing new types of OSS licensing can create a threat to legal compliance and alter the legal status of your software, exposing you to litigation. -How it works: -Early Vulnerability Detection: -The dependency firewall identifies potential issues like security vulnerabilities and license violations at the dependency declaration stage, before they are added to your project. -Blocking Malicious or Risky Packages: -It can block the download of malicious or unsafe open-source packages, preventing them from being integrated into your codebase. -Blocking Vulnerable Builds: -It can prevent the creation of builds that contain high-severity CVEs, operational risks, or other security threats. -Integration with SDLC: -The Cloudsmith Security features are integrated into various SDLC stages, including artifact repositories, CI/CD pipelines, and even IDEs. -Benefits of using the dependency firewall: -Improved Security: -By preventing the entry of vulnerabilities, you reduce the risk of attacks and security incidents. -Enhanced Compliance: -The feature helps ensure compliance with licensing requirements and other regulatory standards. -Reduced Risk: -By blocking builds with high-severity vulnerabilities, you mitigate the risk of introducing security weaknesses into your applications. -Simplified Management: -The Cloudsmith solutions simplify the management of dependencies and make it easier to maintain a secure software supply chain. +what are the (different) approaches you could use to implement the firewall & pros/cons +- promotion workflow +{/* help required here */} +- strict dependency blocking +{/* this workflow is clear */} +aqui estaria bien comparar cada una de las alternativas y ver como se comportan la una con la otra. pros y contras de las mismas. From 81f85dee5f6946a5e66f7b42a62a6a513498a584 Mon Sep 17 00:00:00 2001 From: PabloJLZaldivar Date: Thu, 7 Aug 2025 13:29:13 +0200 Subject: [PATCH 7/8] - --- src/content/guides/dependency_firewall.mdx | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/content/guides/dependency_firewall.mdx b/src/content/guides/dependency_firewall.mdx index 45810774..85d00ba4 100644 --- a/src/content/guides/dependency_firewall.mdx +++ b/src/content/guides/dependency_firewall.mdx @@ -57,10 +57,6 @@ Here's an overview of the different areas we'll cover: 3.4. Licenses 4. Policies - - ---- - ### 1. Control of dependencies For some organizations, there's a common ausence of visibility over OSS software usage in any of the stages of their Software Development Life Cycle (SDLC). Everything is allowed to ship new features fast, leading to a point in which it is almost impossible to track which packages have been running, with the consequent increase in risk. The first step to take control is to increase visibility: you can't control what you don't see. From 777ef7d33e74c7371ad7943a8f01444679b2cd61 Mon Sep 17 00:00:00 2001 From: PabloJLZaldivar Date: Thu, 7 Aug 2025 14:03:58 +0200 Subject: [PATCH 8/8] - --- src/content/guides/dependency_firewall.mdx | 23 +++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/src/content/guides/dependency_firewall.mdx b/src/content/guides/dependency_firewall.mdx index 85d00ba4..8f17b2d5 100644 --- a/src/content/guides/dependency_firewall.mdx +++ b/src/content/guides/dependency_firewall.mdx @@ -19,7 +19,14 @@ Super important to: OPEN QUSTIONS - what about transitive dependencies? can we catch it all? If not, which alternatives we suggest to customers? +- cloudsmith terraform provider, easy to setup sample to create dev, stg and prod repos. anything else we can automate with CTP? +- package promotions, how to automate? +- cloudsmith repo as a cloudsmith upstream repo, any workaround? This would be key to add into this guide +what are the (different) approaches you could use to implement the firewall & pros/cons +- promotion workflow +- strict dependency blocking +help required here I think we can merge both for this guide */} @@ -48,6 +55,7 @@ No matter if you are a Cloudsmith customer or not, you can [sign-up for a trial ## Building a Dependency Firewall Here's an overview of the different areas we'll cover: +0. Setup (CTP) 1. Control of Dependencies 2. Upstream Proxying and Caching 3. Artifact Advisories @@ -71,7 +79,7 @@ code . It contains a microservices app composed of a node frontend, python backend, and a mariadb database, all of them prepared to be deployed in a Kubernetes cluster. -Although there two sample apps together don't sum up more than 100 lines of code, the number of dependencies required to execute them is surprising. For example, browse to the frontend app directory and use `npx howfat` to list information about dependencies in use: +Although there two sample apps together don't sum up more than 100 lines of code, the number of dependencies required to execute them is surprisingly high. For example, browse to the frontend app directory and use `npx howfat` to list information about dependencies in use: ```bash cd frontend @@ -94,6 +102,7 @@ Let's [create a repository](https://docs.cloudsmith.com/repositories/create-a-re Our new repo is created! +{/* update this with broadcasts, probably better to remove it */} Depending on your use case or how you want to distribute your software, you have different visibility options for your repositories: - Public - Private @@ -235,8 +244,8 @@ Now, we not only block dependencies from other external repositories, but also h ### 3. Artifact Advisories - -Advisories, what are they? +{/* +Not sure if EPM or legacy policies */} #### 3.1. Malware @@ -293,8 +302,6 @@ Defense in depth: multiple layers, onion. Not only checking incoming vulnerabili - - 4. Licenses License Compliance Risks: Open source software can contain a dizzying variety of licenses. Inadvertently introducing new types of OSS licensing can create a threat to legal compliance and alter the legal status of your software, exposing you to litigation. @@ -302,9 +309,3 @@ License Compliance Risks: Open source software can contain a dizzying variety of -what are the (different) approaches you could use to implement the firewall & pros/cons -- promotion workflow -{/* help required here */} -- strict dependency blocking -{/* this workflow is clear */} -aqui estaria bien comparar cada una de las alternativas y ver como se comportan la una con la otra. pros y contras de las mismas.