student@hack3rs:~$ cat sources-and-references-policy.md
Sources and References Policy (Official Docs First)
hack3rs.ca prioritizes official documentation, standards, and primary references where practical, then teaches how to interpret and apply that information in defensive workflows.
prerequisites
- $Interest in white-hat network security learning.
1. Primary Source Preference
For tools, standards, and protocols, official project documentation and primary standards references are used where available. Reading the actual docs rather than a third-party summary is a skill in itself — it scales, it stays current, and it builds the habit of going to the source.
Third-party articles can be useful context, but the site avoids long quotations and encourages readers to verify current behavior directly in official docs and authorized lab tests.
Tool behavior changes across versions. A reference that was accurate two years ago may not reflect current defaults. The site aims to point toward sources that update with the tool.
2. How References Are Used
References support the explanation — they are not a substitute for it. Content here focuses on why a tool exists, what evidence it produces, what defenders use it for, and how to use it responsibly in a workflow. The links help readers continue from there.
Source links are selected for depth: official docs, release notes, standards, and practical references that support ongoing learning rather than one-time reads.
Keep your own version-aware notes. A command that worked in Suricata 6.x may behave differently in 7.x. Site content is a starting point, not a maintenance-free reference.
3. Reader Responsibility
Tool behavior, platform defaults, and vendor implementations change. Validate commands and configurations in your own environment before using them operationally.
Use content here as a workflow and concept guide, then confirm specifics against official documentation, your change control process, and internal runbooks.
The most reliable defenders combine documentation reading with lab validation and disciplined notes. Neither alone is sufficient.
sources-policy-checklist
- $Official project docs and primary standards references are preferred over third-party summaries.
- $References support the explanation rather than replace it.
- $Readers should validate commands in lab environments before production use.
- $Keep version-aware notes — tool behavior changes between major releases.
- $Official documentation is the final authority when site content and current docs differ.