OSSEC HIDS: six jobs in C, and a README whose links still point at the master branch

Six detection jobs share one agent and one C tree

The project describes itself as an open source host-based intrusion detection system that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response, and the README goes further, calling it a full platform that mixes host-based intrusion detection, log monitoring and SIM or SIEM work into one solution. The implementation is C, and the root listing is organised by function rather than by packaging: `src/` for the code, `etc/` for configuration, `active-response/` for the part of the system that acts on an alert, `contrib/` for contributed pieces and `doc/` for documentation. That directory layout is the honest description of the design. The system reads logs, watches files for changes, evaluates policy, raises alerts and can then run something in response, and the split between `etc/` and `active-response/` is where the configuration side ends and the response side begins.

The README's own links still address the master branch

The repository's default branch is `main`, and the README's links were not updated to match. The license badge points at `https://github.com/ossec/ossec-hids/blob/master/LICENSE`, and that URL is hardcoded to `master` while the branch a clone lands on is `main`, so a reader following the license link by hand can land on a path that no longer carries the file. The same mismatch explains why the README's first line reads `OSSEC v4.4.0`: the version is written into the text by hand rather than generated from a tag, while the newest release is 4.4.1, published on 2026-10-18. Small thing, but it is the kind of drift that tells you the README is written by people who ship releases rather than by people who keep docs in step with branches.

Three routes to the same binary, and none of them in the README

A reader looking for OSSEC has to choose between three sources. The first badge in the README links to the GitHub releases page, where 4.4.1, 4.4.0 and 4.3.0 are published. The Releases section of the same README says the current stable releases are on the project website instead, with one link for downloads and one for documentation. The Development section then points at GitHub and describes the development version as a plain clone away, with no steps of its own:

git clone https://github.com/ossec/ossec-hids.git

The homepage recorded for the project is `http://www.ossec.net`, plain HTTP. So the download decision is made before you read anything about the software: release assets on GitHub, tarballs and documentation on the website, source from a clone. The release numbers also tell you the cadence is fast, with 4.3.0 published on 2026-08-25, 4.4.0 on 2026-10-05 and 4.4.1 on 2026-10-18, which means the website copy and a pinned GitHub tag can differ by a month of work.

install.sh and an RPM spec sit beside CONFIG and INSTALL

The root of the repository is where the packaging story lives. `install.sh` is a shell installer, `ossec-hids.spec` is an RPM spec file, and next to them sit `INSTALL` and `CONFIG` as plain text, plus `BUGS`, `CONTRIBUTORS`, `CHANGELOG.md`, `SUPPORT.md` and `SECURITY.md`. Having both a shell installer and an RPM spec means the same tree supports a manual install and a packaged one, which is the practical reason the C build produces something usable on a managed fleet. The README itself contributes no install command, no configure flags and no service unit, and the files it points at for that information are on the documentation site. Anyone evaluating OSSEC from the README alone will find no explanation of what the installer asks, what it writes, or what has to be configured before the first alert can fire.

OpenSSL sha1 and blowfish travel inside a GPLv2 tree

The license is the GNU General Public License version 2, with a `LICENSE` file at the root. The Credits section also names what came from elsewhere: a modified version of zlib, a small part of openssl covering the sha1 and blowfish libraries, cryptographic software written by Eric Young, code from the zlib project by Jean-loup Gailly and Mark Adler, and software from the cJSON project by Dave Gamble. The credits also thank Atomicorp for hosting the annual OSSEC conference. None of that is a licence judgement, but it is worth knowing before redistribution: a GPLv2 distribution with bundled third party components needs the component notices kept intact, and the README's credit list is a list of names rather than a statement of which licence applies to each piece. Anyone packaging OSSEC into a product has to read `LICENSE` and each component's own terms rather than relying on the credits list.

Travis beside GitHub Actions, and CodeQL in the badge row

Build configuration shows two eras side by side. `.travis.yml` is still in the repository root, and `.github/` holds the workflows the README advertises, one named for building across platforms and one named for CodeQL. So static analysis and a multi platform build are wired into the GitHub side while a Travis configuration remains on disk. The development notes in the README amount to two badge images and one sentence, and the README gives no list of dependencies and no statement of which operating systems the platform build covers; the root listing has no top-level Makefile or configure script, though it does carry `install.sh` and an `INSTALL` file. For a C project of this size that is the real documentation gap. What ships matters, and how it is built has to be read out of `.github/` and the documentation site rather than off the front page.

The only picture of the interface is two captions

The README has a Screenshots section, and what survives in it is two captions: File Integrity Monitoring and Attack Detection. No configuration file appears, no rule is shown, no alert format is printed, and no default values are given for paths, ports or thresholds. That matters more here than in a project whose rules are self explanatory, because OSSEC is a policy engine: the value of file integrity checking or active response is entirely in the rules an operator writes, and the repository shows none of them. The root listing has a `doc/` directory and a `CONFIG` file that presumably hold more, but the README does not say what is in either. Treat the repository as the place where the code and the packaging live, and the documentation site at the linked docs page as the place where the behaviour is described.

Support runs through Slack, Discord and a conference hosted elsewhere

Two chat channels are named for support, Slack at `ossec.slack.com` with invites sent to `[email protected]`, and a Discord invite link in the README. The annual conference is not run by the project: Atomicorp hosts it, and the README links presentations from the 2019 conference on Atomicorp's own site. That is the whole of the community section, and it has a practical edge to it. If you are picking OSSEC for a fleet, the README names Atomicorp only as the conference host and does not say who maintains the project. Check the licence terms and the support channels against what your organisation expects before standardising on it.

Editorial conclusion

OSSEC suits a team that wants one system covering file integrity checking and log analysis on hosts it already administers, and that is willing to read the project's own documentation site rather than the repository for the setup steps. Nothing here argues against the software itself; the caution is about expectations. The README carries no configuration sample, no rule syntax and no default values, so evaluate the rule syntax on the documentation site before committing a monitoring policy to it. Decide where binaries come from before the first install, because the README points stable releases at the project website, development builds at GitHub, and the GitHub releases page carries 4.4.1, 4.4.0 and 4.3.0 at the same time. Check the bundled third party code before redistributing anything, since the credits name a modified zlib, part of OpenSSL covering sha1 and blowfish, and code from the cJSON project inside a GPLv2 tree.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. ossec/ossec-hids on GitHub
3. Project website
4. README
5. Releases