snyk/cocoapods-lockfile-parser

Generate a Snyk dependency graph from a Podfile.lock file

Getting started with the Snyk CLI

Introduction to Snyk and the Snyk CLI

Snyk is a developer-first, cloud-native security tool to scan and monitor your software development projects for security vulnerabilities. Snyk scans multiple content types for security issues:

• Snyk Open Source: Find and automatically fix open-source vulnerabilities
• Snyk Code: Find and fix vulnerabilities in your application code in real time
• Snyk Container: Find and fix vulnerabilities in container images and Kubernetes applications
• Snyk Infrastructure as Code: Find and fix insecure configurations in Terraform and Kubernetes code

Learn more about what Snyk can do and sign up for a free account.

The Snyk CLI brings the functionality of Snyk into your development workflow. You can run the CLI locally from the command line or in an IDE. You can also run the CLI in your CI/CD pipeline. The following shows an example of Snyk CLI test command output.

Snyk CLI test command output

Snyk CLI scanning supports many languages and tools. For detailed information, see the following:

• Supported languages and frameworks for Open Source and Code
• Supported operating system distributions for Container
• Supported IaC Lanuages and cloud providers

This page explains how to install, authenticate, and start scanning using the CLI. Snyk also has an onboarding wizard to guide you through these steps. For a demonstration, view Starting with Snyk: an overview of the CLI onboarding flow.

Install the Snyk CLI and authenticate your machine

To use the CLI, you must install it and authenticate your machine. See Install or update the Snyk CLI and Authenticate the CLI with your account. You can refer to the release notes for a summary of changes in each release. Before scanning your code, review the Code execution warning for Snyk CLI.

Note: Before you can use the CLI for Open Source scanning, you must install your package manager. The needed third-party tools, such as Gradle or Maven, must be in the PATH.

You can use the CLI in your IDE or CI/CD environment. For details, see Install as part of a Snyk integration.

Test your installation

After authenticating, you can test your installation. For a quick test, run snyk --help.

Alternatively, you can perform a quick test on a public npm package, for example snyk test ionic.

Look at the test command report in your terminal. The report shows the vulnerabilities Snyk found in the package. For each issue found, Snyk reports the severity of the issue, provides a link to a detailed description, reports the path through which the vulnerable module got into your system, and provides guidance on how to fix the problem.

Scan your development Project

Note: Before using the Snyk CLI to test your Open Source Project for vulnerabilities, with limited exceptions, you must build your Project. For details, see Open Source Projects that must be built before testing.

In addition, depending on the language of your open-source Project, you may need to set up your language environment before using the Snyk CLI. For details, refer to Supported languages, frameworks, and feature availability overview.

After you have installed the CLI and authenticated your machine, to scan an open-source Project, use cd /my/project/ to change the current directory toafolder containing a supported package manifest file, such as package.json, pom.xml, or composer.lock. Then run snyk test. All vulnerabilities identified are listed, including their path and fix guidance.

To scan your source code run snyk code test.

You can scan a Docker image by its tag running, for example: snyk container test ubuntu:18.04.

To scan a Kubernetes (K8s) file run the following:
snyk iac test /path/to/kubernetes_file.yaml

For details about using the Snyk CLI to scan each content type, see the following:

• Snyk CLI for Snyk Open Source and the CLI help for the test and monitor commands
• Snyk CLI for Snyk Code and the Snyk Code CLI help
• Snyk CLI for Snyk Container, including Docker scanning, and the Snyk Container CLI help
• Snyk CLI for Snyk IaC, including Terraform and Kubernetes (K8s) Projects, and the Snyk IAC CLI help

Monitor your Open Source or Container Project

Snyk can monitor your Open Source or Container integrated SCM Project periodically and alert you to new vulnerabilities. To set up your Project to be monitored, run snyk monitor or snyk container monitor.

This creates a snapshot of your current dependencies so Snyk can regularly scan your code. Snyk can then alert you about newly disclosed vulnerabilities as they are introduced or when a previously unavailable patch or upgrade path is created. The following code shows an example of the output of the snyk monitor command.

> snyk monitor
Monitoring /project (project-name)...

Explore this snapshot at
https://app.snyk.io/org/my-org/project/29361c2c-9005-4692
-8df4-88f1c040fa7c/history/e1c994b3-de5d-482b-9281-eab4236c851e

Notifications about newly disclosed issues related to these
dependencies will be emailed to you.

You can log in to your Snyk account and navigate to the Projects page to find the latest snapshot and scan results:

Snyk monitor snapshot and scan results

For more information, see Monitor your Projects at regular intervals.

Running out of tests

Snyk allows unlimited tests for public repositories. If you are on the Free plan, you have a limited number of tests per month. Paid plans have unlimited tests on private and public repositories. If you are on the Free plan and notice that your test count is quickly being used, even with public repositories, you can remedy this by telling Snyk the public url of the repository that is being scanned by the Snyk CLI. This ensures that Snyk does not count a public repository towards the test limits.

If you run out of tests on an open-source Project, follow these steps:

• Run snyk monitor.
• Open the Snyk UI and navigate to the settings of the Project.
• Enter the URL of your open-source repository in Git remote URL.

Additional information about the Snyk CLI

Run snyk help or see the CLI commands and options summary.

See the course Introduction to the Snyk CLI for a quick video training session.

Snyk also provides a cheat sheet (blog post) and a video tutorial.

In particular, see the information about the following options that you may find useful:

• --severity-threshold=low|medium|high|critical: Report only vulnerabilities of the specified level or higher.
• --json: Print results in JSON format.
• --all-projects: Auto-detect all Projects in the working directory.

For detailed information about the CLI, see the CLI docs.

Getting support for the Snyk CLI

Submit a ticket to Snyk support whenever you need help with the Snyk CLI or Snyk in general. Note that Snyk support does not actively monitor GitHub Issues on any Snyk development project.

Contributing to the Snyk CLI

The Snyk CLI project is open-source, but Snyk does not encourage outside contributors.

You may look into design decisions for the Snyk CLI.

The Snyk CLI repository is a monorepo that also covers other projects and tools, such as @snyk/protect, also available at npm package for snyk-protect command.

Security

For any security issues or concerns, see the SECURITY.md file in the GitHub repository.

cocoapods-lockfile-parser's Issues

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

Avoid default exports

Fix root package name

The root package name is currently the default _root, as given by dep-graph’s DepGraphBuilder. Instead it would be nice to be able to inject this when parsing a lockfile / use the basename of the path when reading a lockfile.

Migrate to jest

Dependency original version is lost

Hello guys,

I'm using this to parse a podfile, when creating the relation between a dependency and it's parent the original version (as it was stated in the podfile) gets lost.

{
 "[email protected]" : [ ... ]
}
...
{
    "nodeId": "baz",
    "pkgId": "[email protected]",
    "deps": [{ "nodeId": "foo" }, { "nodeId": "bar" }],
},

In the original podfile

- baz (2.0.1)
 - foo (>= 2.0.0)
 - bar (~> 1.0.0)

I'm interested not only on the actual resolved dependency but also in the original one. Is there any workaround or do I have to transverse the graph again myself to try to get it?