Repository files navigation

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 ourLunaTrace documentation for more information.

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

• LunaTrace: A free alternative to services like GitHub Dependabot orSnyk thatautomatically monitors for your dependencies for vulnerabilities. It automatically integrates with GitHub Pull Requeststo notify you of new CVEsbefore you deploy to production. Try it out in one-click via ourGitHub 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 againstLog4Shell, scanning running processes on your system, and more. Follow ourMitigation 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 nameLog4Shell. The blog lives in this repo under/docs/blog if you feellike contributing!
  • Status: Continuously updated and any requests for us to write about topics is encouraged.
• LunaDefend: An end-to-end suite of security software builtaround Tokenization designed toproactively protect your sensitive data from being hacked, as well as providing aneasier 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 pleasejoin 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 totry 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 contributionshere.

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

For more information about LunaSec including tutorials, examples, and technical information, please visitourdocumentation.
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 ourcontributor instructionsbefore 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 ourapproach, we would love to hear from you.

Please email us atdeveloper-feedback at lunasec dot ioor 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.