Our Software
We're a team of Security Engineers on a mission to make awesome Open Source Application Security tooling. It all lives in this repo. Here's a breakdown of everything we've built.
- 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).
- 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: Production ready and maintained (our secondary 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!
Custom Support from the LunaSec Team
We offer paid support, onboarding, and additional enterprise features for LunaSec to help you reach your security or compliance milestones faster. Our team of security engineers is very flexible and happy to work with you.
If you're interested, please send us a message.
Need Help?
If you find yourself stuck, you're missing a feature, or you just want to clear up some confusion, then please head over to our GitHub Discussions board to talk with our team.
We're a small team and our resources are limited for how much assistance we've able to provide. If your needs are urgent, or you would like us to review your code/implementation, then please consider inquiring about our custom support packages.
Contributing
We welcome community contributions, and we've documented the requirements for contributions here.
See Also
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.
Contributing
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.
Feedback
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.
Release Process
The release process will be handled automatically by our CI/CD system.
Under the hood, the release process is split up into four parts:
- Version bump
- Compile artifacts
- Publish artifacts
- 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.
Version
Versioning for releases is done by lerna.
Compile
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.
Publish
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.
Push
The version tag that gets pushed contains the version changes for the bumped monorepo version. Here is an example commit.