carwin / snyk-auto-issues-jira

Snyk Auto-Issues for Jira

This project contains a Forge app written in Javascript that automatically opens Jira issues for issues discovered during Snyk SCA scans.

Users may configure the application on a per-project basis in their Jira environment.

See developer.atlassian.com/platform/forge/ for documentation and tutorials explaining Forge.

Usage

Visit the documentation wiki for information about how to configure and use Snyk Auto-Issues for Jira.

Contributing

System Requirements

• NodeJS (LTS)
• @forge/cli
• Docker (optional)

Installing @forge/cli globally is recommended.

/If you are using the excellent asdf project for NodeJS version management, the .tool-versions file at the root of the repository should ensure your setup is correct with minimal effort./

Prerequisites

• Access to an Atlassian Cloud developer site
• An Atlassian API token

Detailed information about the items in the list above can be found in the Forge developer documentation.

Before you can work with a Forge app in any meaningful way, you'll need to configure the Forge CLI tool. The short version of this process is to simply run:

forge login

For further information, again refer to the Forge developer documentation linked above.

Installing and Running

1. Firstly, the project must be deployed to an environment. The separation/concept of /environments/ within the context of Atlassian Cloud and Jira can be somewhat confusing, but for now it is enough to know that there are typically three environments of interest: development, staging, and production.

   The application is deployed to development, by default, via:

   $ forge deploy

   To deploy to other environments, pass the -e argument with the environment.

2. Once deployed, the application must be installed. This can be accomplished via the administration interface within your Jira project, or via the CLI directly.

   $ forge install

3. (Optional) Once installed, you can forward requests to the application to your local machine which is very useful for debugging. Doing so also enables hot-reloading of the application, allowing you to make changes without needing to constantly redeploy.

   This functionality requires Docker.

   $ forge tunnel

4. At this point, you should head over to the application's settings page within Jira. To do so, find the Project settings link in Jira's sidebar, expand the Apps tree, then select Snyk Auto-Issues for Jira.

5. When the settings have been configured you're ready to develop.

Handy Helpers

If there are major changes you may be required to run the following command after deploying:

$ forge install --upgrade

You can print information about where the application is installed:

$ forge install list

Since this application relies on a webhook, you can generate a callback URL for development using:

$ forge webtrigger

Normally to view the application's logs you'd need to visit the Atlassian cloud developer console, which isn't great if you're looking for something specific.

When working in the development environment with forge tunnel, the logs are streamed live to STDOUT, but for other environments, the best option is forge logs. With no arguments, the data returned can be difficult to parse and mostly appears to have no logical order.

You can view logs grouped by invocation and filtered by environment from the last hour by :

$ forge logs -e production -g -s 1h

snyk-auto-issues-jira's Issues

Which project (issue) types are supported?

This is a request to:

1. Update documentation around which types of Project vulnerabilities are supported in this integration.
2. Support any/all project types from Snyk, specifically the ones mentioned below in the bullet list.

For example, here is a list of all issue types from the Snyk API, though this list looks slightly different in the Snyk "reports/issues" tab in the UI. So not sure which one is the source of truth.

Specifically for our company, we are looking to support auto-creating Jira tickets for vulnerabilities found within the following project types:

• Code
  • react
  • ruby/rails
  • node
• open-source
  • package.json
  • Gemfile.lock
• Dockerfile
• ECR integration (scan containers)
  • And open-source within those containers
    • package.json
    • Gemfile.lock

Support Snyk IaC auto-ticket creation

Related to issue here #3 , but add functionality to support auto-ticket creation for Snyk IaC project types.

Specifically for our company, we are looking to support auto-creating Jira tickets for vulnerabilities found within the following project types:

• Code
  • react
  • ruby/rails
  • node
• Open-source (this integration already supports this 👍🏼)
  • package.json
  • Gemfile.lock
• IaC
  • Dockerfile
  • ECR integration (scan containers)
    • And open-source within those containers
      • package.json
      • Gemfile.lock
  • Kubernetes manifest scans
  • Terraform .tf scans
  • Terraform state scans

This link might be a good starting point in the Snyk API.

[Feature Request] Add further ticket options

Firstly thanks for this tool! Its been sorely missing from Snyk

I would love it if you could add the ability to preconfigure certain ticket variables (E.G:)

• Epic Link
• Labels

We extensively make use of Epics and Labels to categorize and query (filters) our Vuln process in Jira and having these preconfigured would be a major help

Provide visibility into the project to which the vulnerability belongs

The particular use-case here is for 1-to-many mappings. It should be fairly trivial.

Part of the larger request described in #2

Vendor Country is likely wrong

This could reduce people's willingness to try the app.

Allow configurable Assignees for newly created issues

This was on my original roadmap, but I recall running into a pretty significant roadblock. It's worth looking into again, but if anyone wants to take a crack at it I'd appreciate the help.

Part of the larger request described in #2

Link to vulnerabilities within a given Snyk project

Part of the larger request described in #2

Multiple Snyk organizations in a Jira project?

For various reasons we have one Jira project for all development projects, across all teams. But in Snyk each team has a organization. When creating the webhook I found it not possible to create one webhook for the Snyk group, and the documentation also focus on Snyk organizations. Since this tool requires a org service account it is difficult to use it with our Jira setup.

Would it be possible to allow this Jira application to have different configurations in Jira? I.e., so we can have one config for each Snyk organization. For Confluence documentation spaces it looks like this:

Thinking that instead of "Add documentation space" it could be "Add Snyk organization" instead.

I might be able to contribute code to make this work, since this is probably a bit special for my company, but anyways would like to first hear if such a change makes sense or not to you.

Allow configurable Labels for newly created issues

Part of the larger request described in #2

Allow configurable Epic links for newly created issues

Part of the larger request described in #2