Repository: you are reading JacobThree/secureli-modernized — an independent fork. Canonical upstream: slalombuild/seCureLI (Homebrew / PyPI releases, Slalom-maintained docs). Original copyright and Apache 2.0 terms for the upstream codebase still apply here.
This fork is developed separately from Slalom’s release cadence and contributor workflow. Installation for this repository is from source only (git + Poetry); packaged installers are documented for upstream, not here.
I forked seCureLI to keep iterating on tooling and integrations on my own schedule—without tying releases or contributor policy to upstream. Practical goals included tightening how repositories get scaffolded for JavaScript and TypeScript (including ESLint config material under .secureli/), updating CI/pre-commit ergonomics around that flow, and shipping a codebase I can clone, build with Poetry, and run without relying on third-party installers for this fork.
Everything in this subsection is specific to this repository relative to the historic upstream README and typical “install from PyPI/Homebrew” story. For line-by-line code history, use the GitHub compare view (upstream/main → this fork’s main).
| Label | Meaning |
|---|---|
NEW (CLI) |
New or substantially extended commands/flags in this fork’s CLI. Detailed under Usage; each item is also marked inline with This fork. |
NEW (scaffolding) |
Files or layouts written into a target repo when using this fork’s language support. |
DOCS (this fork) |
README / policy only—not necessarily a code change. |
| Item | What it does |
|---|---|
secureli init --dry-run |
Preview init without writing .secureli/, .secureli.yaml, git hooks, or init logs. |
secureli doctor |
Read-only checks (Python version vs package metadata, pre-commit on PATH, hook YAML present/parsable). |
secureli scan --format json |
Machine-readable JSON scan result on stdout. |
secureli scan --format sarif |
SARIF 2.1.0 log on stdout (minimal mapping; see usage notes). |
When JS/TS linters apply, language support writes javascript.eslintrc.yaml and typescript.eslintrc.yaml under .secureli/, matching pre-commit ESLint hooks that reference those paths.
- No Homebrew or PyPI install instructions for this repo—only Installing from source.
- No
CONTRIBUTING.mdhere — upstream’s CONTRIBUTING.md is theirs; this fork does not ship a copy. - Usage subsections below that start with This fork repeat the same features in narrative form next to the rest of the CLI reference.
This fork —
DOCS (this fork)— There is no documented Homebrew or PyPI path for this repository; use upstream if you want those installers.
This is the only supported installation method for this fork.
Prerequisites:
- Git
- Python 3.9 through 3.12 (see
pyproject.tomlfor the current Poetry constraint) - Poetry
Steps:
git clone https://github.com/JacobThree/secureli-modernized.git
cd secureli-modernized
poetry installRun the CLI (either inside poetry shell or via poetry run):
poetry run secureli --helpReading guide: Upstream overview and most of Usage describe seCureLI behavior in general. Any Usage subsection whose first line is a This fork callout documents a feature called out in New and changed in this fork above.
seCureLI is a tool that enables you to experience the delight of building products by helping you get ideas from your head into working software as frictionlessly as possible, in a reliable, secure, scalable, and observable way.
seCureLI:
- scans your local repo for secrets before you commit code to a remote repository
- installs linters based on the code of your project to support security and coding best practices
- configures all the hooks needed so you don’t have to
seCureLI isn’t a magic tool that makes things secure because you have it. It enables a lot of other tools that you could set up individually and helps you as a builder write better code.
Once installed you can see the latest documentation for seCureLI by entering the following on a command prompt:
$ secureli --helpYou will see a list of commands and descriptions of each. You can also pull up documentation for each command with the same pattern. For example:
$ secureli init --help
Usage: secureli init [OPTIONS]
Detect languages and initialize pre-commit hooks and linters for the project
╭─ Options ──────────────────────────────────────────────────────────────────────────────────────╮
│ --reset -r Disregard the installed configuration, if any, and treat as a new install │
│ --yes -y Say 'yes' to every prompt automatically without input │
│ --directory .,-d PATH Run secureli against a specific directory [default: .]
│ --help Show this message and exit. │
╰────────────────────────────────────────────────────────────────────────────────────────────────╯When invoking these commands, you can combine the short versions into a single flag. For example, the following commands are equivalent:
% secureli init --reset --yes
% secureli init -ryAfter seCureLI is installed, you can use it to configure your local git repository with a set of pre-commit hooks appropriate for your repo, based on the languages found in your repo's source code files.
All you need to do is run:
% secureli initRunning secureli init will allow seCureLI to detect the languages in your repo, install pre-commit, install all the appropriate pre-commit hooks for your local repo, run a scan for secrets in your local repo, and update the installed hooks.
This fork —
NEW (CLI)— Previewinitwithout mutating the repo.
To preview what init would do without creating or editing .secureli/, .secureli.yaml, git hooks, or init log files:
secureli init --dry-run --yesYou still get language detection and a short checklist printed to stdout. No automatic secureli update runs after dry-run (--dry-run is for planning only). Use secureli init --help for all init flags.
If you have an existing pre-commit config file you want to preserve when running secureli init, you can use the --preserve-precommit-config flag. This is useful for example when checking out a repo with an existing pre-commit config file.
This fork —
NEW (CLI)— Read-only environment and config checks.
doctor performs read-only checks useful before or after onboarding a repo:
- Current Python is within the
Requires-Pythonrange published with thesecurelipackage. - The
pre-commitexecutable is onPATH. - When seCureLI metadata says the repo is initialized, the expected hook config YAML exists under
.secureli/and parses.
secureli doctor
secureli doctor --directory path/to/repoExit code 0 when all checks pass; non-zero (doctor-specific) when something fails, with a short actionable message printed to stderr/terminal. Pair with init and scan diagnostics in CI when useful.
To manually trigger a scan, run:
% secureli scanThis will run through all hooks and custom scans, unless a --specific-test option is used. The default is to scan staged files only. To scan all files instead, use the --mode all-files option.
This fork —
NEW (CLI)—jsonandsarifscan formats for automation.
By default (--format text, or omitted), secureli scan prints human-readable hook output. For automation and CI you can emit one document to stdout:
| Value | Meaning |
|---|---|
json |
One JSON object: schema_version plus merged ScanResult fields (successful, output, failures with hook metadata). |
sarif |
One SARIF 2.1.0 log (version, $schema, runs[] with tool.driver.rules and results). Each result uses ruleId = ScanFailure.id (the pre-commit hook id or custom-scan id). The hook repository URL and exitCode appear in message.text and in partialFingerprints as secureli/repo and secureli/exitCode. |
Examples:
secureli scan --format json
secureli scan --format sarifLimitations (SARIF): This output is intentionally minimal versus full ingestion expectations for GitHub Advanced Security and other SARIF viewers. There are no snippets, threaded flow locations, stable fingerprints, remediation blocks, taxonomy references, or real line/column spans from hooks (locations default to line 1, column 1). A consumer may reject or downgrade the log depending on required fields; tighten the mapping after you choose a specific upload path.
Failed scans still exit with a non-zero status (same exit code as plain text mode).
This fork —
NEW (CLI)(example) — CI pattern for--format json. The snippet usespip install securelias a short stand-in for “install thesecurelipackage”; for this fork’s supported path, install from a checkout with Poetry instead (see Installing from source).
Minimal workflow to run secureli in CI and persist JSON results (fails the job if hooks report issues—the same behavior as text mode):
# .github/workflows/secureli-scan.yml — requires the repo already initialized with seCureLI
# (`secureli init` locally, committing `.secureli/` metadata and hook config).
name: seCureLI scan
on:
pull_request:
push:
branches: [main]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.12'
- name: Install seCureLI
run: pip install secureli
- name: Run scan (JSON to artifact-friendly stdout)
shell: bash
run: |
set -eo pipefail
secureli scan --mode all-files --format json | tee scan-result.json
# Optional — SARIF suitable for archiving or uploads that accept SARIF 2.1.0 logs:
# - run: secureli scan --mode all-files --format sarif > secureli-scan.sarif
# Optional quick environment check — does not mutate the repo:
# - run: secureli doctorAdjust python-version and triggers to match your project. Interpret scan-result.json in a follow-up step (e.g. upload with actions/upload-artifact) if you want the file retained after the step.
By default, seCureLI will only scan files that are staged for commit. If you want to scan a different set of files, you can use the --file parameter. You can specify multiple files by passing the parameter multiple times, e.g. --file file1 --file file2.
seCureLI utilizes its own PII scan, rather than using an existing pre-commit hook. To exclude a line from being flagged by the PII scanner, you can use a disable-pii-scan marker in a comment to disable the scan for that line.
test_var = "some dummy data I don't want scanned" # disable-pii-scan
seCureLI utilizes its own custom regex scan to flag any text that matches a user provided regex pattern. To include a regex pattern in the scan simply add the pattern to your .secureli.yaml by running
secureli update --new-pattern <your-custom-regex>
This fork —
NEW (scaffolding)— For JavaScript and TypeScript, this checkout also emitsjavascript.eslintrc.yaml/typescript.eslintrc.yamlunder.secureli/when those linters apply (see New and changed in this fork).
seCureLI has Slalom-maintained templates for security management of the following languages.
- Java
- Python
- Terraform
- JavaScript
- TypeScript
- C#
- Swift
- Golang
- Kotlin
This fork —
DOCS (this fork)— Replaces upstream “upgrade via Homebrew/pip” for this repo.
Pull the latest changes for this fork and reinstall dependencies:
git pull
poetry installPackaged upgrades (Homebrew or PyPI) apply to upstream only, not this repository.
In order to upgrade to the latest released version of each pre-commit hook configured for your repo, use the following command.
secureli update --latest
seCureLI is configurable via a .secureli.yaml file present in the root of your local repository.
| Key | Description |
|---|---|
repo_files |
Affects how seCureLI will interpret the repository, both for language analysis and as it executes various linters. |
echo |
Adjusts how seCureLI will print information to the user. |
language_support |
Affects seCureLI's language analysis and support phase. |
pii_scanner |
Includes options for seCureLI's PII scanner |
telemetry |
Includes options for seCureLI telemetry/api logging |
| Key | Description |
|---|---|
max_file_size |
A number in bytes. Files over this size will not be considered during language analysis, for speed purposes. Default: 100000 |
ignored_file_extensions |
Which file extensions not to consider during language analysis. |
exclude_file_patterns |
Which file patterns to ignore during language analysis and code analysis execution. Use a typical file pattern you might find in a .gitignore file, such as *.py or tests/. Certain patterns you will have to wrap in double-quotes for the entry to be valid YAML. |
| Key | Description |
|---|---|
level |
The log level to display to the user. Defaults to ERROR, which includes error and print messages, without including warnings or info messages. |
| Key | Description |
|---|---|
ignored_extensions |
The extensions of files to ignore in addition to the defaults. |
| Key | Description |
|---|---|
api_url |
The url endpoint to post telemetry logs to. This value is an alternative to setting the url as an environment variable. Note: The environment variable will precede this setting value |
pre-commit is used for configuring pre-commit hooks. The configuration file is .secureli/.pre-commit-config.yaml, relative to the root of your repo. For details on modifying this file, see the pre-commit documentation on configuring hooks.
If there is a .pre-commit-config file in your root when you initialize seCureLI, it will be merged with the default configuration written to .secureli/.pre-commit-config.yaml.
Special care needs to be taken when passing arguments to pre-commit hooks in .pre-commit-config.yaml. In particular, if you're passing parameters which themselves take arguments, you must ensure that both the parameter and its arguments are separate items in the array.
Examples:
BAD
- args:
- --exclude-files *.mdThis is an array with a single element, ["--exclude files *.md"]. This probably won't work as you're expecting.
GOOD
- args:
- --exclude-files
- *.mdThis is an array where the parameter and its argument are separate items; ["--exclude files", "*.md"]
ALSO GOOD
- args: ["--exclude-files", "*.md"]This file is generated by seCureLI and contains the configuration for the repo.
It is not intended to be modified by the user. Running secureli update will
update this file with the latest configuration.
seCureLI can send secret detection events to an observability platform, such as New Relic. Other platforms may also work, but have not been tested. Should you need seCureLI to work with other platforms, please create a new issue in github, or contribute to the open source project.
- Assuming, seCureLI has been setup and installed, sign up to New Relic Log Platform https://docs.newrelic.com/docs/logs/log-api/introduction-log-api/
- Retrieve API_KEY and API_ENDPOINT from New Relic. API_ENDPOINT for New Relic should be https://log-api.newrelic.com/log/v1
- On your development machine, setup environment variable with variable name SECURELI_LOGGING_API_KEY and SECURELI_LOGGING_API_ENDPOINT. The endpoint can alternatively be added and commited to source control via the .secureli.yaml file.
- Once the above setup is complete, everytime seCureLI triggered, it should send a usage log to New Relic
- In New Relic, you can create a dashboard of metric to see the number of times secret was caught using query such as
FROM Log Select sum(failure_count_details.detect_secrets) as 'Caught Secret Count'
Copyright 2024 Slalom, Inc.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.