Thank you for your interest in contributing to the Velociraptor project! This repository hosts the Velociraptor documentation website as well as the community-driven Artifact Exchange.
There are two main ways to contribute:
- Improve the documentation itself.
- Submit an artifact to the Artifact Exchange.
Both contribution types use the standard GitHub fork-and-PR workflow, as described below.
If you want to improve the documentation itself (fix typos, add
content, update screenshots, etc.), you can find a full set of
guidelines in the
Documentation Development Guidelines
section of the website. This is also accessible in the repository
under content/dev/ and includes:
- Setting up a Hugo development server — how to get a local live-preview web server running so you can see your changes before submitting.
- Prose style guidelines — writing and formatting standards, markdown flavor tips, page structure conventions, etc.
- Image guidelines — advice for creating screenshots and diagrams (optionally using Excalidraw), and recommendations for image format/size/font/colors/etc.
- Vale linting — how to run our automated prose linter locally.
The general workflow for documentation contributions is:
- Fork this repository.
- Clone your fork locally.
- (Optional) Install Hugo and run
hugo serverfor a live preview. - Make your changes to the markdown content under
content/. - Run
vale .from the project root if you have Vale installed (optional, CI will catch issues). - Commit, push to your fork, and open a Pull Request.
Velociraptor is an open source community-driven project, and we welcome contributions from the community. Velociraptor's VQL language is designed to lower the bar for contributions and make it easier for non-developers to contribute meaningful improvements in the form of new Artifacts.
Tip
Before contributing, consider chatting with us on Discord first. We can help you find the right place for your contribution and avoid wasted effort.
Velociraptor's philosophy is to be as flexible as possible to cater for many different use cases. This means that users usually maintain their own set of custom artifacts that suit their own particular workflows, which is perfectly fine!
However, for custom artifacts contributed back into the project we require that these be useful to the broader Velociraptor community. Artifacts that handle a very specific or unique task are probably not that useful broadly and are unlikely to be accepted as Exchange contributions. On the other hand, if your artifact demonstrates a solution to an interesting or novel use case that others can learn from, then it may be accepted on that basis.
Velociraptor comes with a large number of built-in artifacts ready to use when installed. However, there are also hundreds of artifacts available on the Artifact Exchange.
The main distinction between the two sources is around quality and maintainability:
-
Built-in artifacts are useful to most people and are extensively tested using automated tests. If you wish to contribute to the built-in set you should also include tests. These ensure that the artifacts are less likely to fail in future and help maintain them across releases.
-
The Artifact Exchange contains many artifacts that were useful at one time but may not have been updated recently. These artifacts have no quality assurance and may even break. Since they do not have associated CI tests we may not know they are broken unless someone reports it. Furthermore, many of these artifacts provide integration with third-party systems which we don't have access to, which means we can't verify reported issues or create CI tests for such artifacts.
Good candidates for the Exchange are:
- Artifacts that hunt for specific topical threats which may not be more widely useful in general (for example the Log4J vulnerability which is now widely patched).
- Artifacts that demonstrate a unique or reusable solution to a general class of problem (for example, interacting with various types of external APIs, including LLMs).
If you encounter issues with an Exchange artifact, your best bet is to try fix it yourself (and then contribute the fixed version back) and/or try to contact the original author for assistance. We also plan to review the artifacts in the Exchange periodically and remove outdated or no-longer-working artifacts. On the other hand, very useful Exchange artifacts may be graduated to become built-ins if suitable tests can be devised.
For some common artifact patterns we have dedicated projects that may be a better home for your contribution:
-
Triage artifacts (search for files, collect, hash, enrich): use the Triage Artifact project instead. See the Triage Artifacts site for details.
-
Registry parsing artifacts (search registry keys, parse binary values): use the Registry Hunter project instead.
-
Artifacts targeting web browsers and OS database files (SQLite, LevelDB, ESE): use the SQLiteHunter project instead.
-
Sigma rule-based detections: contribute to our Sigma Rules project instead.
Exchange artifacts are stored in this repository under
content/exchange/artifacts/.
GitHub allows you to create a fork, add a single file, and then make a Pull Request without leaving their website. This is the most common workflow for contributing a single artifact and doesn't require much knowledge of git or version control.
The steps are:
- Fork this repository.
- Add your YAML artifact file to
content/exchange/artifacts/in your fork. - Submit a Pull Request back to this repository.
For more advanced submissions, the process is the same as for a
documentation contribution (described below), except that for
artifacts you're just adding your YAML file into
content/exchange/artifacts/ and you don't need Hugo or any of the
steps related to that.
We'll review your contribution and give you feedback in the Pull Request if anything needs changing.
Note
We don't guarantee that all artifact submissions will be accepted. If you're unsure, please chat with us on Discord first.
-
Use the
velociraptor artifacts verifycommand (or theServer.Utils.ArtifactVerifierserver artifact in the GUI) to validate your artifact. This runs a static analysis of the artifact's VQL to ensure there are no major issues. The CI pipeline will run the verifier automatically on submitted artifacts. -
Author your artifacts using the built-in GUI editor to benefit from its VQL-aware tools and automatic validation. If you prefer to write in an external editor, paste it into the GUI's artifact editor to trigger validation. The built-in editor also includes a "Reformat VQL" button for consistent VQL formatting.
-
Write clear artifact descriptions so that others can understand what the artifact does and how to use it without needing to read the VQL. See the section Tips for creating better artifacts in the documentation for more detailed guidance.
By contributing, you agree that your contributions will be licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.