LunaTrace is an Open Source supply chain security and auditing tool. At its heart is a web console the tracks your projects and their dependencies, looking for vulnerabilities and other issues. This console is provided as a SAAS (available here for free) or you can deploy it and manage it yourself.

Please see our LunaTrace documentation for more information.

We're a team of Security Engineers on a mission to make awesome Open Source Application Security tooling. It all lives in this monorepo and here's a breakdown of where everything we've built lives.

• LunaTrace: A free alternative to services like GitHub Dependabot or Snyk that automatically monitors for your dependencies for vulnerabilities. It automatically integrates with GitHub Pull Requests to notify you of new CVEs before you deploy to production. Try it out in one-click via our GitHub App.
  • Status: Production ready and under active development (our primary focus).
• Log4Shell CLI: A small command line utility to scan for Log4Shell. Also supports patching JAR files against Log4Shell, scanning running processes on your system, and more. Follow our Mitigation Guide for more context.
  • Status: Production ready and used by thousands of companies. Superseded by LunaTrace.
• Our Security Blog: Our ramblings to the internet. This is where we broke the news about the log4j vulnerability and gave it the name Log4Shell. The blog lives in this repo under /docs/blog if you feel like contributing!
  • Status: Continuously updated and any requests for us to write about topics is encouraged.
• LunaDefend: An end-to-end suite of security software built around Tokenization designed to proactively protect your sensitive data from being hacked, as well as providing an easier path towards compliance (SOC2, GDPR, PCI-DSS, etc).
  • Status: Unmaintained (but feel free to open issues).

If you find yourself stuck, you're missing a feature, or you just want to clear up some confusion, then please join our Discord Community to speak with us.

We're a small team and we're always looking for more feedback about what problems we can help solve, so we'd love if you took a moment to try out LunaTrace and, if you like it, share it with your colleagues and friends. The hardest part of our mission to build better security tools is simply getting people to realize that they exist!

We welcome community contributions and we've documented the requirements for contributions here.

If you'd like to contribute ideas or feedback, you can do so by either opening a GitHub issue or speaking with us on Discord.

For more information about LunaSec including tutorials, examples, and technical information, please visit our documentation.
For marketing information, sales, or to get in touch, visit our website: https://www.lunasec.io/.

The rest of this ReadMe explains how to work on LunaSec itself. If you simply want to use LunaSec, please see the documentation.

Please read our contributor instructions before forking and submitting a pull request. It's short and it's very helpful if you're going to be working on LunaSec.

Our goal is to create a sustainable business to support LunaSec, while also building an Open Source community. If you have thoughts on how we can improve our approach, we would love to hear from you.

Please email us at developer-feedback at lunasec dot io or file an issue on this repository.

The release process will be handled automatically by our CI/CD system.

Under the hood, the release process is split up into four parts:

1. Version bump
2. Compile artifacts
3. Publish artifacts
4. Push version tag to repository

Breaking this process up ensures that every part completes without error before moving onto the next step. This greatly reduces the event that some artifacts get published and others do not, leading to a headache of a time debugging a release.

Deployment of the releases is done by GitHub Actions.

Versioning for releases is done by lerna.

Since the monorepo has both go and node code, compilation happens in multiple places. For the node sdks, every package has their own compilation package.json script which gets run. The entrypoint which calls into each package’s script is here. For the go code, all compilation code exists within the Makefile under the release target.

For node artifacts, everything is handled by lerna. For go, publishing is handled by the publish target of the Makefile. Artifacts end up in NPM, DockerHub, and Github.

The version tag that gets pushed contains the version changes for the bumped monorepo version. Here is an example commit.