# Snyk > When you scan a project with the CLI, the`.snyk`policy file may be in a different directory from the manifest file, either because of the structure of the project or because the project has multiple --- # Source: https://docs.snyk.io/developer-tools/snyk-cli/scan-and-maintain-projects-using-the-cli/a-.snyk-policy-file-in-a-different-directory-from-the-manifest-file.md # A .snyk policy file in a different directory from the manifest file When you scan a project with the CLI, the `.snyk` policy file may be in a different directory from the manifest file, either because of the structure of the project or because the project has multiple manifest files using the same policy file. Use the `--policy-path` option to specify a policy path manually for use in scanning or monitoring the project. {% hint style="info" %} This option is not supported for projects imported using Git (SCM) integrations. {% endhint %} --- # Source: https://docs.snyk.io/snyk-api/using-specific-snyk-apis/snyk-apps-apis/about-snyk-apps.md # About Snyk Apps Snyk Apps are integrations that extend the functionality of the Snyk platform, allowing you to create a Snyk experience to suit your specific needs. For example, a Snyk App might automate Snyk [application security testing](https://snyk.io/learn/application-security/testing/) as part of a build tool. Another Snyk App might stream Snyk security testing results into an incident management tool. You can create your own reporting, metrics, or even a user management App. You can move your automated Snyk API scripts and transform them into a Snyk App, which will add a better UX/UI experience for your Snyk Organization users. The easiest way to start building a new Snyk App is to clone the [Demo Snyk Apps ](https://github.com/snyk/snyk-apps-demo)GitHub repository. You can either modify the demo to suit your App design or use it as a base for creating your own Snyk App. See the [Snyk Apps blog post](https://snyk.io/blog/snyk-apps-beta-build-custom-apps-extend-snyk-security-into-workflows/) for more details. This document describes how to create a new Snyk App in the language of your choice. Use this document along with the [API reference documentation for Snyk Apps](https://docs.snyk.io/snyk-api/reference/apps). Snyk Apps are based on the [Snyk API](https://docs.snyk.io/snyk-api/snyk-api) so that your integrations are inherently stable and secure. ## Integrating Apps with Snyk The Snyk Apps platform uses an [OAuth 2.0](http://oauth.net/2/) authorization flow. This allows your Snyk App to get an access token to act on behalf of the user or Tenant, depending on the scopes you request. There are many OAuth 2.0 libraries available that will greatly simplify the integration. The [Snyk Apps Demo](https://github.com/snyk/snyk-apps-demo) uses the popular JavaScript library [passport.js](http://www.passportjs.org/packages/passport-oauth2/). See the Snyk [OAuth2 API documentation](https://docs.snyk.io/snyk-api/oauth2-api) for details. ## How do Apps connect? When a Snyk App is created, it is set up to use `a specific context`, either `tenant` or `user`. Set this with the `context` field if you are creating a Snyk App with the API or the `--context` flag if you are using the CLI. If the `context` is not specified, a Snyk App will default to the `tenant` context, which is preferred unless your Snyk App specifically needs to perform operations as an individual user. ### User context Authorizing a Snyk App that has the `user` context grants the Snyk App access to perform actions on behalf of the user. The Snyk App will have access to the same set of Organizations and Groups as the installing user, as well as access to any new Snyk Organizations and Groups the user is added to. If the installing user deactivates their account, any installed apps having the `user` context that user has installed will lose access to Snyk. ### Tenant context When a user authorizes a Snyk App that has the `tenant` context, the user selects the way to connect to either a Snyk Organization or a Group, with access to either all or one of the Organizations in the Group. The resulting connection is no longer tied to that specific user, so it is not bound by the user’s access or lifecycle but is linked to the lifecycle of the Organization. For more information, see [Organizations](https://docs.snyk.io/snyk-platform-administration/groups-and-organizations/organizations) and [Groups](https://docs.snyk.io/snyk-platform-administration/groups-and-organizations/groups). The `scopes` of an App determine which actions an App can perform while connected to a Snyk account. The`scopes` are related to actions performed through Snyk Organizations, which determine the API endpoints that can be used in an App. Endpoints authorized through a Snyk Group are not supported. For more information about scopes, see [Scopes to request](https://docs.snyk.io/snyk-api/using-specific-snyk-apis/snyk-apps-apis/scopes-to-request). ### Snyk Organization ID The final step for the integration process is to [get the ID of the Snyk Organization the user has authorized](https://docs.snyk.io/snyk-api/using-specific-snyk-apis/snyk-apps-apis/set-up-a-snyk-app-using-the-oauth2-api/retrieve-the-app-org-ids). This ID is needed to use most API endpoints, so the App must associate it with the user's account or workspace for future use. ## Managing Snyk Apps from the UI Snyk provides a user-friendly interface for managing your authorized Snyk Apps. This allows you to easily view and control which Apps have access to your Snyk account. ### Open the Management UI Navigate to your personal **Account Settings** and select the **Authorized Snyk Apps** option. You can also navigate directly to the [Authorized Snyk Apps page](https://app.snyk.io/account/manage/authorized-apps) or open the page from your Organization **Settings**.
Snyk Apps management UI

Snyk Apps management UI

### Revoking a Snyk App from the management UI On the Authorized Snyk Apps page, you will see a list of all the Snyk Apps that you have integrated and authorized. The page displays relevant information about each App, including the date when it was authorized. If you wish to revoke access for a particular Snyk App: * Locate the specific App in the list of authorized Apps. * Click the **Revoke** button next to the App. Revoking access will prevent the App from further accessing your Snyk account and performing actions on your behalf. This gives you full control over which Apps can interact with your Snyk data and ensures that you can manage your App integrations securely. By using the Snyk Apps management UI, you can maintain a clear overview of your authorized Apps and make adjustments to their access as needed, enhancing the security and customization of your Snyk experience. --- # Source: https://docs.snyk.io/snyk-api/rest-api/about-the-rest-api.md # About the REST API The Snyk REST API is based on the [JSON:API standard](https://jsonapi.org/), defined in [OpenAPI 3.0.3](https://spec.openapis.org/oas/v3.0.3.html), and represents an evolutionary approach to API development, with each endpoint versioned. For more information, see the [Versioning](#versioning) section on this page. ## API URLs Snyk is hosted in the following regions. Each region has its own base URL. Use the URL for your region when calling an API.
RegionBase URL
SNYK-US-01https://api.snyk.io/rest
SNYK-US-02https://api.us.snyk.io/rest
SNYK-EU-01https://api.eu.snyk.io/rest
SNYK-AU-01https://api.au.snyk.io/rest
{% hint style="info" %} This API is available only over HTTPS. Calling this API over HTTP will yield a 404 for all requests. {% endhint %} ## JSON:API Content-Type header The Snyk REST API generally adheres to the [JSON:API standard](https://jsonapi.org/), with some [caveats](https://github.com/snyk/sweater-comb/blob/main/docs/principles/jsonapi.md). JSON:API is an opinionated specification for how a client should request and modify resources and how a server should respond to requests. When using the REST API, send all requests which contain data with the header: ``` Content-Type: application/vnd.api+json ``` Otherwise a 400 "Bad Request" response will be returned. ```json HTTP/1.1 400 Bad Request { "errors": [ { "status": "400", "detail": "Client request did not conform to OpenAPI specification", ... } ] } ``` ## Versioning ### Using versions dated on or after 2024-10-15 The API Reference examples include `?version=text` as a placeholder, where `text` represents the required date-formatted version string. Snyk recommends using `2024-10-15` for the version number unless you are using an earlier version for a specific reason. You can use the current day's date; this will call the most recent version of the API. The format for the date is `YYYY-MM-DD`. ### Using versions dated prior to 2024-10-15 The following information applies to calling versions earlier than 2024-10-15. The Snyk REST API has per-endpoint version contracts. For information about the differences in GA versions, see the [API Changelog](https://docs.snyk.io/snyk-api/changelog). Each endpoint can have its own release and support lifecycle, independent of any other endpoint in the Snyk REST API. In its most explicit form, the endpoint version number includes a date and stability tree, for example: ``` 2023-11-27~beta ``` This version number indicates that the requested endpoint should be at stability level `2023-11-27` or older `beta`. The possible stability levels are: * `ga` - Generally Available, the default. Snyk will support these for at least six months after the next GA release. * `beta` - Beta. Snyk will support these for at least three months after the next beta or GA release. * `experimental` - Experimental. An experimental endpoint should be considered unstable and regarded as a tech preview. Experimental versions may introduce breaking changes and may be discontinued at any time. In the default case of Generally Available, there is no stability level specified in the version number itself, that is, only the date is present, for example: ``` 2023-11-27 ``` This means the requested endpoint should be 2023-11-27 or older on the Generally Available stability tree. When the requested endpoint is at a specific stability level, Snyk serves the latest version, the version released on or before the requested date, or that stability or higher. For example, if the requested endpoint has a beta version at 2023-09-29 and GA version at 2024-01-23, and the requested endpoint is after 2024-01-23\~beta, Snyk resolves to the GA version. Granular version controls enable Snyk to introduce progressive enhancements. These may require small or minor backward-incompatible changes. However, using granular version controls means Snyk can deliver rapid enhancements more quickly while supporting existing endpoints for a guaranteed period of time. After an endpoint is marked as deprecated, it will contain a `Sunset` header indicating the date at which that endpoint contract will no longer be supported. For example: ``` Sunset: "2021-11-11" ``` ## Pagination All endpoints in the Snyk REST API are paginated using *cursor-based* pagination. This form of pagination helps prevent inconsistent results when collections are modified while they are being iterated. However, cursor-based pagination does not totally prevent inconsistent results, which can occur, for example, if an item is inserted in a prior page based on the sort order requested after a request is made. To mitigate the possibility of inconsistent results, by default, Snyk sorts by insertion order, so it is not possible to have items inserted on a prior page. However, if you specify the `sort` parameter, consistent pagination is no longer guaranteed. If you see inconsistent results, you can submit a new request. If consistent pagination is important to your workflow, use the default insertion sort order. Whenever you receive an API response, it will contain appropriate links in the body of the response as follows: ```json { "data": [ ... ], "links": { "prev": "/orgs/123-abc-def-456/projects?version=2024-06-10&ending_before=v1.eyJpZCI6Mz1zODQyMH0%3D" "next": "/orgs/123-abc-def-456/projects?version=2024-06-10&starting_after=v1.eyJpZCI6Mz1zODQyMH0%3D" } } ``` These links contain pre-defined parameters to make pagination easy. These parameters are a combination of: * `starting_after`: an opaque (Snyk internal) blob that tells Snyk the *last record* you have seen and that you want records *after* this last one * `ending_before`: an opaque (Snyk internal) blob that tells Snyk the *first record* you have seen and that you want records *before* this first one * `limit`: the number of records per page ## Errors Errors conform to the JSON:API specification and include path-based information to indicate the root cause as follows: ```json { "errors": [ { "id": "0418e907-a89e-4736-9a5b-91a2022e0899", "detail": "Unknown query parameter 'unknown'", "status": "400", "source": { "parameter": "unknown" } } ] } ``` ## Rate limiting There is a limit of **1620 requests per minute**, per API key. All requests above the limit will get a response with the status code `429` - `Too many requests` until requests stop for the duration of the rate-limiting interval (one minute). From time to time, Snyk may introduce new rate limits to maintain overall system health. This is not considered a breaking change. All clients are expected to handle the `429` responses correctly and such requests can be retried later safely. --- # Source: https://docs.snyk.io/snyk-api/using-specific-snyk-apis/webhooks-apis/about-webhooks.md # About webhooks {% hint style="warning" %} The Webhooks API is in beta. While the API is in beta, Snyk may change the API and the structure of webhook payloads at any time, without notice. During this beta, Webhooks are available only in the Snyk US-01, US-02, EU-01, and AU-01 regions. {% endhint %} Webhooks allow you to be notified of Snyk system events, enabling you to build notifications and react to changes in your projects. The current implementation supports events for recurring scans of open source and container image related projects. When events are triggered, Snyk sends HTTP POST requests to URLs you have configured for those events, with all the information you need. ## Example use cases ### Notifications Receive instant notifications/alerts in your organization's business communication/collaboration software. ### Incident Response Respond to critical issues before they impact your business. Embrace modern incident management and Snyk to stay ahead of application security. Read more about this use case in the blog ["Shifting left security incident management with the Snyk & Opsgenie integration"](https://snyk.io/blog/security-incident-management-snyk-opsgenie-integration/). ### Security Information and Event Management (SIEM) Get real-time security alerts aggregated across various sources into a single platform. Read more about Snyk's partnership with Rapid7 and how together we help organizations mitigate security risks. ### Vulnerability Management and Aggregation Browse the various [Snyk Partner integrations](https://docs.snyk.io/integrations/partner-integrations) for a comprehensive list of solutions. ## Security SSL Webhooks can only be configured for URLs using the HTTPS protocol. HTTP is not allowed. ## Request signing When creating a webhook, you must provide a ​secret​ - this is a string that only you know that we will use to sign our transports to you so that you can ensure they come from Snyk. Your secret should be: * A random string with high entropy * Not be used for anything else * Only known to Snyk and your webhook transport consuming code All transports sent to your webhooks will have a ​`X-Hub-Signature` ​header, which contains the hash signature for the transport. The signature is a HMAC hexdigest of the request body, generated using sha256 and your secret as the HMAC key. {% hint style="info" %} `X-Hub-Signature​` always starts with​ `sha256=` {% endhint %} --- # Source: https://docs.snyk.io/developer-tools/snyk-cli/security-concept-of-operations-for-snyk/access-requirements.md # Access requirements When you are using Snyk applications like the [CLI ](https://docs.snyk.io/developer-tools/snyk-cli/getting-started-with-the-snyk-cli)or [IDE integrations](https://docs.snyk.io/developer-tools/snyk-ide-plugins-and-extensions), certain local and remote resources must be accessible. This documentation explains how to harden your system without affecting Snyk functionality. ## Local filesystem The required filesystem access may vary by product. * CACHE\_PATH (Read,Write,Execute) * Windows: `C:\\Users\\\\AppData\\Local\\snyk` * Linux/Alpine: `/home//.cache/snyk` * macOS: `/Users//Library/Caches/snyk` * CONFIG\_PATH (Read,Write) * Windows: `%USERPROFILE%\\.config\\configstore` * Linux: `$HOME/.config/configstore` * macOs: `$HOME/.config/configstore` ## Network resources ### Required * api.\.io:443 * app.\.io:443 * 127.0.0.1:\ * required for Inter Process Communication * [Ephemeral Port Range](https://www.rfc-editor.org/rfc/rfc6335.html#section-6) might vary by Operating System and Settings ### Optional * deeproxy.snyk.io:443 (for Snyk Code) * downloads.snyk.io:443 (depending on features used, such as downloading the CLI) * learn.snyk.io:443 (to be able to display Snyk Learn links in issue details) * static.snyk.io:443 (depending on features used, such as downloading the CLI) * snyk.io:443 (depending on features used) * \*.sentry.io:443 (error reporting) --- # Source: https://docs.snyk.io/snyk-api/reference/accessrequests.md # AccessRequests {% hint style="info" %} This document uses the REST API. For more details, see the [Authentication for API](https://docs.snyk.io/snyk-api/authentication-for-api) page. {% endhint %} {% openapi src="" path="/self/access\_requests" method="get" %} [rest-spec.json](https://2533899886-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MdwVZ6HOZriajCf5nXH%2Fuploads%2Fgit-blob-42ebe7ebbe084db5ba66cf53a50453b68b5c9ab0%2Frest-spec.json?alt=media) {% endopenapi %} --- # Source: https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/universal-broker/add-a-new-connection-to-your-universal-broker.md # Add a new connection to your Universal Broker To add a new connection, run `snyk-broker-config workflows connections create`. If prompted, select the desired deployment. Then follow the prompts to create the connection of the desired type. For details, see [Setting up and integrating your Universal Broker connections](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/universal-broker/setting-up-and-integrating-your-universal-broker-connections). Note the following information about Broker deployments. A Broker deployment supports numerous connections of any type, including the same type. This means, for example, that a Broker deployment can support multiple GitLab connections. There is a limit of 25 connections for one deployment. While the Universal Broker supports multiple connections of the same type, each Organization can be integrated with only one connection for a given type. For example, an Organization cannot be integrated with two GitLab connections. You can share credentials references across connections by selecting a credentials reference when you create a connection. However, you can share credentials references only across connections of the same type and running on the same Broker deployment After the connection is created, run `snyk-broker-config workflows connections integrate` and select the desired deployment and connection. Then enter the Organization ID for the Organization with which you want to integrate. For details, see [Integrate a connection with an Organization](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/setting-up-and-integrating-your-universal-broker-connections#integrate-a-connection-with-an-organization). If you integrate a connection already integrated with an Organization, the previous integration will be lost in favor of the new one. Be sure to paste the correct Organization ID. --- # Source: https://docs.snyk.io/implementation-and-setup/enterprise-implementation-guide/phase-6-rolling-out-the-prevention-stage/add-and-configure-snyk-in-your-ci-cd-pipeline.md # Add and configure Snyk in your CI/CD pipeline Using Snyk as a gatekeeper in your build pipeline prevents the introduction of new vulnerabilities. based on the fail criteria you set. After your teams understand the vulnerabilities in their applications and develop a process for fixing them early in the development cycle, you can configure Snyk to fail your builds if vulnerabilities are detected, to prevent introducing vulnerabilities into your applications. ## No import requirement A benefit of adding tests to your pipeline is that you do not need to import the repository to Snyk using source control integration, which is required for Snyk PR Checks. Adding tests to your pipeline can also be used as an additional gate, even if you are testing PRs, to further decrease the chance of new vulnerabilities entering your production builds. ## Pipeline options When adding Snyk to a build pipeline, you have these common options: * Using the specific [pipeline integration](https://docs.snyk.io/developer-tools/snyk-ci-cd-integrations) for your tool. * Using the [Snyk CLI](https://docs.snyk.io/developer-tools/snyk-cli) and running the specific commands directly. Each option has benefits; using an existing pipeline integration may be faster and easier to configure, but using the Snyk CLI will give you a greater range of options and flexibility in your fail criteria. ## Pipeline test filters When you run a test in your pipeline, you can use filters to determine what would result in a test's passing or failing. The most common of these is severity threshold, where you can specify to fail a build only if there are High or Critical severity vulnerabilities. ## CLI supporting tools When you use the Snyk CLI in your pipeline, you can use a range of supporting [CLI Tools](https://docs.snyk.io/developer-tools/snyk-cli/scan-and-maintain-projects-using-the-cli/cli-tools) that provide additional functionality, including: * [snyk-delta,](https://docs.snyk.io/developer-tools/snyk-cli/scan-and-maintain-projects-using-the-cli/cli-tools/snyk-delta) which can be used to compare two sets of results and identify new vulnerabilities, similar to how the PR Checks feature tests for new vulnerabilities only * [snyk-filter](https://docs.snyk.io/developer-tools/snyk-cli/scan-and-maintain-projects-using-the-cli/cli-tools/snyk-filter), which can be used for more complex fail criteria, such as `fail if more than three High severity vulnerabilities are found`. ## Additional information [CI/CD Best Practices](https://www.youtube.com/watch?v=6QS9gRQ0WVU) is a webinar that covers CI/CD checks in more detail and includes an example of how you can gradually introduce this feature. --- # Source: https://docs.snyk.io/implementation-and-setup/team-implementation-guide/phase-5-rolling-out-the-prevention-stage/add-and-configure-snyk-to-your-ci-cd-pipeline.md # Add and configure Snyk to your CI/CD pipeline Using Snyk as a gatekeeper in your build pipeline prevents the introduction of new vulnerabilities, based on the "fail" criteria you set. After your teams understand the vulnerabilities in their applications and develop a process for fixing them early in the development cycle, you can configure Snyk to fail your builds if vulnerabilities are detected, to prevent introducing vulnerabilities into your applications. ## No import requirement A benefit of adding tests to your pipeline is that you do not need to import the repository to Snyk using the source control integration (which is required for Snyk PR Checks). It can also be used as an additional gate, even if you are testing PRs, to further decrease the chance of new vulnerabilities entering your production builds. ## Pipeline options When adding Snyk to a build pipeline, there are common options: * Using the specific [pipeline integration](https://docs.snyk.io/developer-tools/snyk-ci-cd-integrations) for your tool. * Using the [Snyk CLI](https://docs.snyk.io/developer-tools/snyk-cli) and running the specific commands directly. Each option has benefits - using an existing pipeline integration may be faster and easier to configure, but using the Snyk CLI will give you a greater range of options and flexibility in your "fail" criteria. ## Pipeline test filters When running a test in your pipeline, there are filters available to determine what would result in a test passing or failing. The most common of these is "severity threshold", where you can specify to only fail a build if there are High or Critical severity vulnerabilities. ## CLI supporting tools If you use the Snyk CLI in your pipeline, a range of supporting [Snyk Tools](https://docs.snyk.io/scan-with-snyk/snyk-tools) provide additional functionality, including [`snyk-filter`](https://docs.snyk.io/developer-tools/snyk-cli/scan-and-maintain-projects-using-the-cli/cli-tools/snyk-filter), which can be used for more complex "fail" criteria, such as “fail if more than three High severity vulnerabilities are found”. ## Also see Here is a link to a webinar that covers CI/CD checks in more detail and includes an example of how you can gradually introduce this feature: [CI/CD Best Practices](https://www.youtube.com/watch?v=6QS9gRQ0WVU). --- # Source: https://docs.snyk.io/scan-with-snyk/snyk-container/container-registry-integrations/integrate-with-jfrog-artifactory/add-artifactory-images-to-snyk.md # Add Artifactory images to Snyk Snyk tests and monitors your Artifactory container images by evaluating the tags in your repositories. ## **Prerequisites for adding Artifactory images** * You must have an account with Snyk and be onboarded to your Organization by an administrator. * The integration must be configured between Snyk and your Artifactory environment. ## **Steps to adding Artifactory images to Snyk** * Log in to your account and navigate to the relevant Group and Organization you want to manage. * Go to **Projects** and click **Add projects**. The list of integrations already configured on your account opens. * The view **Which images do you want to test?** opens, displaying all of the available images for the registry to which you connected, grouped by each of your repositories. * Select single or multiple images using any or all of the following methods: * Type the name of a single image for import in the Image Name field (at number 1, the image name field, in the image above), * Select any of the repositories if you want to import all of the associated images (at number 2, the second item listed in the image above). * Expand and collapse repositories to select multiple images (at number 3, the third image listed in the image above) across multiple repositories. * Click **Add selected repositories**. A status bar appears at the top of the page as the images are imported; you can continue working in the meantime. * When the import ends, a notification of success or failure appears at the top of the page. Click Refresh to view the Projects page with the newly imported images. Images are grouped by repository and are each linked individually to a detailed Projects page. * You can now connect your Git repo to this Project in order to use your Dockerfile for enriched fix advice. For more information, see [Adding your Dockerfile and testing your base image](https://docs.snyk.io/scan-with-snyk/snyk-container/scan-your-dockerfile/detect-vulnerable-base-images-from-your-dockerfile). Images are indicated with a unique icon. You can filter to view only the Artifactory Projects.
List of Artifactory Projects

List of Artifactory Projects

Artifactory integration works like other Snyk integrations. To continue to monitor, fix and manage your Projects, see the relevant pages in the Snyk user documentation. {% hint style="info" %} For application vulnerabilities within container images, any changes to the application will not be reflected with a manual or recurring retest. A re-import of the image is required. For more information, see [Detecting application vulnerabilities in container images](https://docs.snyk.io/scan-with-snyk/snyk-container/use-snyk-container/detect-application-vulnerabilities-in-container-images). {% endhint %} --- # Source: https://docs.snyk.io/scan-with-snyk/snyk-container/container-registry-integrations/integrate-with-microsoft-azure-container-registry-acr/add-images-to-snyk-from-acr.md # Add images to Snyk from ACR Snyk tests and monitors Microsoft Azure Container Registry (ACR) container images by evaluating root folders and custom file locations. ## **Prerequisites to add images to Snyk from ACR** * You must have an account with Snyk and be onboarded to your Organization by an administrator. * The integration must be configured between Snyk and your ACR repository. ## Steps to add images to Snyk from ACR 1. Log in to your account and navigate to the relevant Group and Organization you want to manage. 2. Go to **Projects**, and click **Add projects**. The list of integrations already configured on your account opens. The view **Which images do you want to test?** opens, displaying all of the available images for the registry to which you connected, grouped by each of your repositories, similar to the following: 1. Select single or multiple images using any or all of the following methods: 1. Type the name of a single image for import in the **Image Name** field (at number 1, the Image Name field in the image above), 2. Select any of the repositories if you want to import all of the associated images (at number 2, the second item listed in the image above). 3. Expand and collapse repositories to select multiple images at number 3, the third item listed in the image above) across multiple repositories. 2. Click **Add selected repositories**. A status bar appears at the top of the page as the images are imported; you can continue working in the meantime. 3. When the import ends, a notification of success or failure appears at the top of the page. Click **Refresh** to view the **Projects** page with the newly imported images.\ Images are grouped by repository and linked individually to a detailed Projects page. 4. You can now connect your Git repository to this Project in order to use your Dockerfile for enriched fix advice.\ For more information, see [Adding your Dockerfile and testing your base image](https://docs.snyk.io/scan-with-snyk/snyk-container/scan-your-dockerfile/detect-vulnerable-base-images-from-your-dockerfile). ACR files are indicated with a unique icon. You can filter to view only ACR Projects. ACR integration works like other Snyk integrations. To continue to monitor, fix and manage your Projects, see the relevant pages in the Snyk user documentation. {% hint style="info" %} For application vulnerabilities within container images, any changes to the application will not be reflected with a manual or recurring retest. A re-import of the image is required. For more information, see [Detecting application vulnerabilities in container images](https://docs.snyk.io/scan-with-snyk/snyk-container/use-snyk-container/detect-application-vulnerabilities-in-container-images). {% endhint %} --- # Source: https://docs.snyk.io/scan-with-snyk/snyk-container/container-registry-integrations/integrate-with-amazon-elastic-container-registry-ecr/add-more-organizations-to-your-aws-iam-role-for-snyk-authentication.md # Add more Organizations to your AWS IAM role for Snyk authentication After creating an AWS IAM role for Snyk, you can add more Organizations to the same role for repeated use. 1. In [Snyk](https://app.snyk.io/), retrieve and copy the IDs for any additional Snyk Organizations that you want to integrate and save the IDs so you can paste them into a script in the subsequent steps. 2. In AWS, navigate to the **Trust relationships** tab for the role you want to update with additional Organizations. 3. Click **Edit trust relationship**. Ensure the value of "sts:ExternalId" is enclosed with square brackets and insert the additional Organization ID inside those brackets. Use a comma ( , ) to separate between Organization ID values. For example: ``` "sts:ExternalId": [ "11111111-1111-1111-1111-111111111111", "22222222-2222-2222-2222-222222222222", "c2fa1651-601d-41gc-abe9-03691f5287d8" ] ``` Where: `"11111111-1111-1111-1111-111111111111"` = a unique Org ID `"22222222-2222-2222-2222-222222222222"` = another unique Org ID `"c2fa1651-601d-41gc-abe9-03691f5287d8"` = the ID for the Organization from which you are currently setting up the integration --- # Source: https://docs.snyk.io/implementation-and-setup/team-implementation-guide/phase-3-gain-visibility/add-project-attributes.md # Add project attributes After importing your projects, you can add metadata to your Projects using [Project Attributes](https://docs.snyk.io/snyk-platform-administration/snyk-projects/project-attributes). This allows you to filter and report on specific subsets of your Organization. For example, if you add Project Attributes to all of your Projects, you can easily filter Projects to those that are "frontend critical vulnerabilities in production" from the Projects page. --- # Source: https://docs.snyk.io/implementation-and-setup/enterprise-implementation-guide/phase-3-gain-visibility/add-project-tags-and-attributes.md # Add Project tags and attributes After importing your Projects, you can add metadata using [Project attributes](https://docs.snyk.io/snyk-platform-administration/snyk-projects/project-attributes) or [Project tags](https://docs.snyk.io/snyk-platform-administration/snyk-projects/project-tags). This makes it easier to filter and report on specific subsets of your Organization. For example, if you add both Project attributes including `frontend` and a tag of `Team:Unicorn` to all of your Projects that a specific Dev Team owns, you can easily generate a report of frontend critical vulnerabilities in production that team Unicorn owns. Attributes and tags are also useful features that can be used to configure [Project collections and Project views](https://docs.snyk.io/snyk-platform-administration/snyk-projects/project-collections-groupings), making it easier for you to view Projects in a grouping that makes sense to you. --- # Source: https://docs.snyk.io/developer-tools/snyk-ci-cd-integrations/azure-pipelines-integration/add-the-snyk-security-task-to-your-pipelines.md # Add the Snyk Security Task to your pipelines ## **Prerequisites to add Snyk Security Task to your pipelines** * Ensure you have a pipeline within the repository for the code you want to test. * If you created a pipeline with the Azure Repos wizard, this file is called `azure-pipelines.yml`. * If this repository has multiple service connections, ask your Snyk admin which to use for your pipeline. * If you want to add your Dockerfile for additional base image data to use when testing your container, ensure the image has been built. ## **Requirements to add Snyk Security Task to your pipelines** This extension requires that Node.js and npm be installed on the build agent. These are available by default on all Microsoft-hosted build agents. However, if you are using a self-hosted build agent, you may need to explicitly activate Node.js and npm and ensure they are in your [PATH](https://en.wikipedia.org/wiki/PATH_\(variable\)). This can be done using the [NodeTool task from Microsoft](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/tool/node-js?view=azure-devops) prior to adding the Snyk Security Scan task to your pipeline. ## **Steps to add Snyk Security Task to your pipelines** 1. Add the Snyk Security Scan task when you create your pipeline or while editing an existing one. See the [Azure Pipelines documentation](https://docs.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops). 2. From Azure, access the pipeline that you want to scan for vulnerabilities. Open it for editing and check that the Build step is included just before the point at which you want to insert the Snyk task. Note that this is not required but is considered best practice for consistency across projects. 3. Open the **assistant**, search for the Snyk Security Scan task, and click it as shown in the screen image that follows. The configuration panel opens on top of the assistant.\\

Search for the Snyk Security Scan Task

4. Complete the fields in the configuration. 1. Find full details about the parameters on the page [Snyk Security Scan task parameters and values](https://docs.snyk.io/developer-tools/snyk-ci-cd-integrations/azure-pipelines-integration/snyk-security-scan-task-parameters-and-values). 2. Note that if you check the **Fail build if Snyk finds issue** option, when the build fails the pipeline job is failed by the Snyk task. 3. If you uncheck the **Fail build if Snyk finds issue** option, the Snyk task tests for vulnerabilities but does not cause the pipeline job to fail. 4. When testing a container image, you can specify the path to the Dockerfile with the dockerfilePath property to receive additional information about issues in your base image. 5. To add your Dockerfile for additional base image data when testing your container, ensure the image has been built. 5. Place your cursor inside the pipeline, ensuring you place it before a deployment step, such as **npm publish** or **docker push**. 1. You can have multiple instances of the Snyk Security Scan task within your pipeline. 2. This might be useful, for example, if you have multiple project manifest files you want to test or if you want to test both the application and the container images. 6. From the configuration panel, click **Add**. The task is inserted into your pipeline where your cursor was placed, similar to the following: ``` - task: SnykSecurityScan@1 inputs: testType: 'app' monitorWhen: 'always' failOnIssues: true ``` After the task is included in your pipeline, the task runs each time the pipeline runs, and the results appear in the Azure Pipelines output view: ![Azure pipelines output view](https://2533899886-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MdwVZ6HOZriajCf5nXH%2Fuploads%2Fgit-blob-7fff1d15893ef6f67c741c5b5dcd77750e80e800%2Fuuid-d570e34b-3973-2044-598b-cb89c82a1db0-en.png?alt=media\&token=57bc0f2d-8854-4b17-b1d9-09998381ebfd) If the Snyk task fails the build, an error message appears in the results indicating that the build failed due to `snyk test`. --- # Source: https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-helm-chart-installation.md # Advanced configuration for Helm Chart installation {% hint style="info" %} **Multi-tenant settings for regions other than the default**\ When you set up Snyk Broker for use in regions other than the default, additional environment variables with specific URLs are required. For the URLs and examples, see [Regional hosting and data residency, Broker URLs](https://docs.snyk.io/snyk-data-and-governance/regional-hosting-and-data-residency#broker-server-urls). {% endhint %} When you set up Snyk Broker using Helm, you can set advanced parameters as explained on the following pages: * [Custom additional options for Broker Helm Chart installation](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-helm-chart-installation/custom-additional-options-for-broker-helm-chart-installation) * [Ingress options with Snyk Broker Helm installation](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-helm-chart-installation/ingress-options-with-snyk-broker-helm-installation) * [Deploying multiple Brokers in the same namespace](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-helm-chart-installation/deploying-multiple-brokers-in-the-same-namespace) * [Service accounts for Helm Chart installation](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-helm-chart-installation/service-accounts-for-helm-chart-installation) * [Multi-tenant settings for Helm chart installation](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-helm-chart-installation/multi-tenant-settings-for-helm-chart-installation) * [Snyk Open Source scans (SCA) of large manifest files, Helm setup](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-helm-chart-installation/snyk-open-source-scans-sca-of-large-manifest-files-helm-setup) * [Kubernetes secrets and Helm Chart installation](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-helm-chart-installation/kubernetes-secrets-and-helm-chart-installation) * [Image repository, tab, and image Pull Secret](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-helm-chart-installation/image-repository-tab-and-image-pull-secret) * [Insecure Downstream Mode](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-helm-chart-installation/insecure-downstream-mode) * [Proxy settings for Broker Helm chart installation](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-helm-chart-installation/proxy-settings-for-broker-helm-chart-installation) * [Parameters for troubleshooting and providing your own certificate with Helm](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-helm-chart-installation/parameters-for-troubleshooting-and-providing-your-own-certificate-with-helm) * [Credential pooling with Docker and Helm](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-snyk-broker-docker-installation/credential-pooling-with-docker-and-helm) --- # Source: https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-snyk-broker-docker-installation.md # Advanced configuration for Snyk Broker Docker installation {% hint style="info" %} **Multi-tenant settings for regions other than the default**\ When you set up Snyk Broker for use in regions other than the default, additional environment variables with specific URLs are required. For the URLs and examples, see [Regional hosting and data residency, Broker URLs](https://docs.snyk.io/snyk-data-and-governance/regional-hosting-and-data-residency#broker-server-urls). {% endhint %} When you install using Docker, follow these instructions to configure Broker as needed: * [Changing the auth method with Docker](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-snyk-broker-docker-installation/changing-the-auth-method-with-docker) * [Credential pooling with Docker and Helm](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-snyk-broker-docker-installation/credential-pooling-with-docker-and-helm) * [HTTPS for Broker Client with Docker](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/https-for-broker-client-with-docker) * [Backend requests with an internal certificate for Docker](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-snyk-broker-docker-installation/backend-requests-with-an-internal-certificate-for-docker) * [Proxy support with Docker](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-snyk-broker-docker-installation/proxy-support-with-docker) * [Disable certificate verification with Docker](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-snyk-broker-docker-installation/disable-certificate-verification-with-docker) * [Mounting secrets with Docker](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-snyk-broker-docker-installation/mounting-secrets-with-docker) * Snyk Code - [Clone an integration across your Snyk Organizations](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/clone-an-integration-across-your-snyk-organizations) * [Snyk Open Source Scans (SCA) of large manifest files for Docker](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-snyk-broker-docker-installation/snyk-open-source-scans-sca-of-large-manifest-files-docker-setup) * [Insecure Downstream Mode](https://docs.snyk.io/implementation-and-setup/enterprise-setup/snyk-broker/classic-broker/install-and-configure-snyk-broker/advanced-configuration-for-snyk-broker-docker-installation/insecure-downstream-mode) --- # Source: https://docs.snyk.io/developer-tools/snyk-cli/scan-and-maintain-projects-using-the-cli/snyk-cli-for-snyk-container/advanced-use-of-snyk-container-cli.md # Advanced use of Snyk Container CLI ## Scan archives In addition to scanning images from a local Docker daemon or remote registry, Snyk can directly scan or monitor a Docker or Open Container Initiative (OCI) archive when you use the following commands: * `snyk container test docker-archive:.tar` * OR `snyk container test oci-archive:.tar.` Beginning with CLI version 1.1296.0, you can scan and monitor Kaniko image archives using the following commands: * `snyk container test kaniko-archive:.tar` * `snyk container monitor kaniko-archive:.tar`. Beginning with CLI version 1.1297.0, you can scan and monitor image archives without specifying the archive type: * `snyk container test .tar` * `snyk container monitor .tar`. This update maintains full support for the current CLI scanning features and ensures backward compatibility. Examples: ``` snyk container test docker-archive:archive.tar snyk container test oci-archive:archive.tar snyk container test kaniko-archive:archive.tar snyk container test archive.tar ``` {% hint style="info" %} For`Crane`, Snyk supports only the formats `--format=oci` and`--format=legacy`. {% endhint %} ## Test multi-platform images Some repositories represent multi-manifests, pointing to several different images depending on the operating system and the architecture required. To explicitly scan an image for a specific platform, you can use the Snyk CLI `container test` command, for example: ``` snyk container test --platform=linux/arm64 debian ``` The `--platform` option must contain one of the following: * linux/amd64 * linux/arm64 * linux/riscv64 * linux/ppc64le * linux/s390x * linux/386 * linux/arm/v7 * linux/arm/v ## Authenticate to a remote container registry When Docker is installed, the Snyk CLI `container` commands use any pre-configured registry authentication. If you are not using Docker, you can pass the credentials on the command line in one of the following ways: * Use the following environment variables: `SNYK_REGISTRY_USERNAME` and `SNYK_REGISTRY_PASSWORD` * Pass the username and password: ``` snyk container test : --username= --password= ``` {% hint style="info" %} When both are passed, the options take precedence over the environment variables. {% endhint %} ## Use an alternate Docker context The Snyk CLI `container` commands always use the default [Docker context](https://docs.docker.com/engine/manage-resources/contexts/). To force the Snyk CLI to use an alternate context's connection, set the `DOCKER_HOST` environment variable to the desired context URI. ## Other commonly used CLI options Frequently used CLI options include: * `--json` - useful for integrating with other tools * `--sarif` - useful for integrating with other tools. The option is available only with `container test`. See also [OASIS Static Analysis Results Interchange Format (SARIF)](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif). * `--exclude-base-image-vulns` - only available with `container test` * `--severity-threshold` - available only with `container test` * `--exclude-app-vulns` * `--nested-jars-depth` * `--fail-on` - available only with `container test` For more details and CLI options, see the [Snyk CLI container help ](https://docs.snyk.io/developer-tools/snyk-cli/commands/container)or display the help by running: ``` snyk container --help ``` --- # Source: https://docs.snyk.io/snyk-api/reference/aibom.md # Source: https://docs.snyk.io/developer-tools/snyk-cli/commands/aibom.md # AI-BOM **Note**: AI-BOM is an experimental feature and is subject to breaking changes without notice. If you are using AI-BOM, Snyk recommends installing the Snyk CLI from the [release](https://docs.snyk.io/developer-tools/releases-and-channels-for-the-snyk-cli#stable) channel. ## Prerequisites * The `snyk aibom` feature requires an internet connection. * Snyk CLI v1.1298.3 (or later). * Your Project must be written in Python and using a [package manager](https://docs.snyk.io/supported-languages/supported-languages-list/python) supported by Snyk. ## Usage `$ snyk aibom --experimental [