{"id":13539395,"url":"https://github.com/stevenaldinger/decker","last_synced_at":"2026-02-16T07:11:24.501Z","repository":{"id":44173533,"uuid":"159779307","full_name":"stevenaldinger/decker","owner":"stevenaldinger","description":"Declarative penetration testing orchestration framework","archived":false,"fork":false,"pushed_at":"2019-12-20T21:26:49.000Z","size":160,"stargazers_count":292,"open_issues_count":4,"forks_count":26,"subscribers_count":11,"default_branch":"master","last_synced_at":"2025-08-15T12:37:09.442Z","etag":null,"topics":["automation","decker","docker","framework","go","golang","hacking","hcl","kali","linux","orchestration","penetration","security","testing"],"latest_commit_sha":null,"homepage":null,"language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/stevenaldinger.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"docs/contributing.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2018-11-30T06:34:29.000Z","updated_at":"2025-04-17T02:23:57.000Z","dependencies_parsed_at":"2022-09-26T18:01:45.847Z","dependency_job_id":null,"html_url":"https://github.com/stevenaldinger/decker","commit_stats":null,"previous_names":[],"tags_count":22,"template":false,"template_full_name":null,"purl":"pkg:github/stevenaldinger/decker","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stevenaldinger%2Fdecker","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stevenaldinger%2Fdecker/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stevenaldinger%2Fdecker/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stevenaldinger%2Fdecker/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/stevenaldinger","download_url":"https://codeload.github.com/stevenaldinger/decker/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stevenaldinger%2Fdecker/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29502933,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-16T05:57:17.024Z","status":"ssl_error","status_checked_at":"2026-02-16T05:56:49.929Z","response_time":115,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["automation","decker","docker","framework","go","golang","hacking","hcl","kali","linux","orchestration","penetration","security","testing"],"created_at":"2024-08-01T09:01:25.011Z","updated_at":"2026-02-16T07:11:24.487Z","avatar_url":"https://github.com/stevenaldinger.png","language":"Go","readme":"[![Build Status](https://cloud.drone.io/api/badges/stevenaldinger/decker/status.svg)](https://cloud.drone.io/stevenaldinger/decker)\n\n# Decker - Penetration Testing Orchestration Framework\n\n## Purpose\n\n`Decker` is a penetration testing orchestration framework. It leverages [HashiCorp Configuration Language 2](https://github.com/hashicorp/hcl2) (the same config language as [Terraform](https://github.com/hashicorp/terraform)) to allow declarative `penetration testing as code`, so your tests can be versioned, shared, reused, and collaborated on with your team or the community.\n\nExample of a `decker` config file:\n\n```hcl\n// variables are pulled from environment\n//   ex: DECKER_TARGET_HOST\n// they will be available throughout the config files as var.*\n//   ex: ${var.target_host}\nvariable \"target_host\" {\n  type = \"string\"\n}\n\n// resources refer to plugins\n// resources need unique names so plugins can be used more than once\n// they are declared with the form: 'resource \"plugin_name\" \"unique_name\" {}'\n// their outputs will be available to others using the form unique_name.*\n//   ex: nmap.443\nresource \"nmap\" \"nmap\" {\n  host = \"${var.target_host}\"\n  plugin_enabled = \"true\"\n}\nresource \"sslscan\" \"sslscan\" {\n  host = \"${var.target_host}\"\n  plugin_enabled = \"${nmap.443 == \"open\"}\"\n}\n```\n\nRun a plugin for each item in a list:\n\n```hcl\nvariable \"target_host\" {\n  type = \"string\"\n}\nresource \"nslookup\" \"nslookup\" {\n  dns_server = \"8.8.4.4\"\n  host = \"${var.target_host}\"\n}\nresource \"metasploit\" \"metasploit\" {\n  for_each = \"${nslookup.ip_address}\"\n  exploit = \"auxiliary/scanner/portscan/tcp\"\n  options = {\n    RHOSTS = \"${each.key}/32\"\n    INTERFACE = \"eth0\"\n  }\n}\n```\n\nComplex configuration combining `for_each` with nested values:\n\n```hcl\nvariable \"target_host\" {\n  type = \"string\"\n}\nresource \"nslookup\" \"nslookup\" {\n  dns_server = \"8.8.4.4\"\n  host = \"${var.target_host}\"\n}\nresource \"nmap\" \"nmap\" {\n  for_each = \"${nslookup.ip_address}\"\n  host = \"${each.key}\"\n}\n// for each IP, check if nmap found port 25 open.\n// if yes, run metasploit's smtp_enum scanner\nresource \"metasploit\" \"metasploit\" {\n  for_each = \"${nslookup.ip_address}\"\n  exploit = \"auxiliary/scanner/smtp/smtp_enum\"\n  options = {\n    RHOSTS = \"${each.key}\"\n  }\n  plugin_enabled = \"${nmap[\"${each.key}\"].25 == \"open\"}\"\n}\n\n```\n\n## Output formats\n\nSeveral output formats are available and more than one can be selected at the same time.\n\nSetting `DECKER_OUTPUTS_JSON` or `DECKER_OUTPUTS_XML` to `\"true\"` will output `json` and `xml` formatted files respectively.\n\n1. Output `.json` files in addition to plain text: `export DECKER_OUTPUTS_JSON=\"true\"`\n2. Output `.xml` files in addition to plain text: `export DECKER_OUTPUTS_XML=\"true\"`\n\n## Why the name decker?\n\nMy friend [Courtney](https://github.com/courtneymiller2010) came to the rescue when I was struggling to come up with a name and found [decker](http://www.catb.org/esr/sf-words/glossary.html#decker) in a [SciFi word glossary](http://www.catb.org/esr/sf-words/glossary.html)... and it sounded cool.\n\n\u003e A future cracker; a software expert skilled at manipulating cyberspace, especially at circumventing security precautions.\n\n## Running an example config with docker\n\nTwo volumes are mounted:\n\n1. Directory named `decker-reports` where `decker` will output a file for each plugin executed. The file's name will be `{unique_resource_name}.report.txt`.\n2. `examples` directory containing `decker` config files. Mounting this volume allows you to write configs locally using your favorite editor and still run them within the container.\n\nOne environment variable is passed in:\n\n1. `DECKER_TARGET_HOST`\n\nThis is referenced in the config files as `{var.target_host}`. `Decker` will loop through all environment variables named `DECKER_*`, stripping away the prefix and setting the rest to lowercase.\n\n```sh\ndocker run -it --rm \\\n  -v \"$(pwd)/decker-reports/\":/tmp/reports/ \\\n  -v \"$(pwd)/examples/\":/decker-config/ \\\n  -e DECKER_TARGET_HOST=example.com \\\n stevenaldinger/decker:kali decker ./decker-config/example.hcl\n```\n\nWhen `decker` finishes running the config, look in `./decker-reports` for the outputs.\n\n## Running an example config without docker\n\nYou'll likely want to set the directory `decker` writes reports to with the `DECKER_REPORTS_DIR` environment variable.\n\nSomething like this would be appropriate. Just make sure whatever you set it to is an existing directory.\n\n```sh\nexport DECKER_REPORTS_DIR=\"$HOME/decker-reports\"\n```\n\nYou'll also need to set a target host if you're running one of the example config files.\n\n```sh\nexport DECKER_TARGET_HOST=\"\u003cinsert hostname here\u003e\"\n```\n\nThen just run a config file. Change to the root directory of this repo and run:\n\n```sh\n./decker ./examples/example.hcl\n```\n\n## Contributing\n\nContributions are very welcome and appreciated. See [docs/contributions.md](docs/contributions.md) for guidelines.\n\n## Development\n\nUsing docker for development is recommended for a smooth experience. This ensures all dependencies will be installed and ready to go.\n\nRefer to `Directory Structure` below for an overview of the go code.\n\n### Quick Start\n\n1. (on host machine): `make docker_build`\n2. (on host machine): `make docker_run` (will start docker container and open an interactive bash session)\n3. (inside container): `dep ensure -v`\n3. (inside container): `make build_all`\n4. (inside container): `make run`\n\n### Initialize git hooks\n\nRun `make init` to add a `pre-commit` script that will run [linting](https://github.com/golang/lint) and tests on each commit.\n\n### Plugin Development\n\n`Decker` itself is just a framework that reads config files, determines dependencies in the config files, and runs plugins in an order that ensures plugins with dependencies on other plugins (output of one plugin being an input for another) run after the ones they depend on.\n\nThe real power of `decker` comes from plugins. Developing a plugin can be as simple or as complex as you want it to be, as long as the end result is a `.so` file containing the compiled plugin code and a `.hcl` file in the same directory declaring the inputs the plugin is expecting a user to configure.\n\nCheck out [docs/building_plugins.md](./docs/building_plugins.md) to get started on your first plugin. It should only take you a few minutes to get a \"Hello World\" `decker` plugin running.\n\n## Installing plugins\n\nBy default, plugins are expected to be in a directory relative to wherever the `decker` binary is, at `\u003cdecker binary\u003e/internal/app/decker/plugins/\u003cplugin name\u003e/\u003cplugin name\u003e.so`. Additional paths can be added by setting the `DECKER_PLUGIN_DIRS` environment variable. The default plugin path will still be used if `DECKER_PLUGIN_DIRS` is set.\n\nExample: `export DECKER_PLUGIN_DIRS=\"/path/to/my/plugins:/additional/path/to/plugins\"`\n\nThere should be an `HCL` file next to the `.so` file at `\u003cdecker binary\u003e/internal/app/decker/plugins/\u003cplugin name\u003e/\u003cplugin name\u003e.hcl` that defines its inputs and outputs. Currently, only `string`, `list`, and `map` inputs are supported. Each input should have an `input` block that looks like this:\n\n```\ninput \"my_input\" {\n  type = \"string\"\n  default = \"some default value\"\n}\n```\n\n## Directory Structure\n\n```\n.\n├── build\n│   ├── ci/\n│   └── package/\n├── cmd\n│   ├── decker\n│   │   └── main.go\n│   └── README.md\n├── deployments/\n├── docs/\n├── examples\n│   └── example.hcl\n├── githooks\n│   ├── pre-commit\n├── Gopkg.toml\n├── internal\n│   ├── app\n│   │   └── decker\n│   │       └── plugins\n│   │           ├── a2sv\n│   │           │   ├── a2sv.hcl\n│   │           │   ├── main.go\n│   │           │   └── README.md\n│   │           └── ...\n│   │               ├── main.go\n│   │               ├── README.md\n│   │               └── xxx.hcl\n│   ├── pkg\n│   │   ├── dependencies/\n│   │   ├── gocty/\n│   │   ├── hcl/\n│   │   ├── paths/\n│   │   ├── plugins/\n│   │   └── reports/\n│   └── README.md\n├── LICENSE\n├── Makefile\n├── README.md\n└── scripts\n    ├── build-plugins.sh\n    └── README.md\n```\n\n- [cmd/decker/main.go](cmd/decker/main.go) is the driver. Its job is to parse a given [config file](examples/), load the appropriate plugins based on the file's `resource` blocks, and run the plugins with the specified inputs.\n- [examples](examples/) has a couple example configurations to get you started with `decker`. If you use the kali [docker image](https://hub.docker.com/r/stevenaldinger/decker/) (`stevenaldinger/decker:kali`), all dependencies should be installed for all config files and things should run smoothly.\n- [internal/pkg](internal/pkg) is where most of the actual code is. It contains all the packages imported by [main.go](cmd/decker/main.go).\n  * [dependencies](internal/pkg/dependencies) is responsible for building the plugin dependency graph and returning a topologically sorted array that ensures plugins are run in a working order.\n  * [gocty](internal/pkg/gocty) offers helpers for encoding and decoding [go-cty](https://github.com/zclconf/go-cty) values which are used to handle dynamic input types.\n  * [hcl](internal/pkg/hcl) is responsible for parsing HCL files, including creating evaluation contexts that let blocks properly decode when they depend on other plugin blocks.\n  * [paths](internal/pkg/paths) is responsible for returning file paths for the `decker` binary, config files, plugin config files, and generated reports.\n  * [plugins](internal/pkg/plugins) is responsible for determining if plugins are enabled and running them.\n  * [reports](internal/pkg/reports) is responsible for writing reports to the file system.\n- [internal/app/decker/plugins](internal/app/decker/plugins) are modular pieces of code written as [Golang plugins](https://golang.org/pkg/plugin/), implementing a simple interface that allows them to be loaded and called at run-time with inputs and outputs specified in the plugin's config file (also in HCL). An example can be found at [internal/app/decker/plugins/nslookup/nslookup.hcl](internal/app/decker/plugins/nslookup/nslookup.hcl).\n- [decker config files](examples) offer a declarative way to write penetration tests. The manifests are written in [HashiCorp Configuration Language 2](https://godoc.org/github.com/hashicorp/hcl2/hcl)) and describe the set of plugins to be used in the test as well as their inputs.\n","funding_links":[],"categories":["\u003ca id=\"1233584261c0cd5224b6e90a98cc9a94\"\u003e\u003c/a\u003e渗透\u0026\u0026offensive\u0026\u0026渗透框架\u0026\u0026后渗透框架","\u003ca id=\"5dd93fbc2f2ebc8d98672b2d95782af3\"\u003e\u003c/a\u003e工具","automation","Multi-paradigm Frameworks","Tools"],"sub_categories":["\u003ca id=\"2e40f2f1df5d7f93a7de47bf49c24a0e\"\u003e\u003c/a\u003e未分类-Pentest","Forensics","Docker Containers of Penetration Testing Distributions and Tools","Intentionally Vulnerable Systems as Docker Containers","Multi-paradigm Frameworks"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstevenaldinger%2Fdecker","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fstevenaldinger%2Fdecker","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstevenaldinger%2Fdecker/lists"}