Baseline-check is a compliance auditor that runs as two shell scripts

Two scripts, two reports, and a warning you should read first

Baseline-check is a Windows and Linux system security baseline checking tool, described as hand written in the sense that the code was written by hand rather than generated, providing comprehensive security compliance checking. The repository contains almost nothing: a readme, a Linux script, a Windows script, and one Word document per platform describing the baseline configuration. There is no package manager entry, no installer and no framework, which is a fair reflection of what it is. A system administrator downloads the script for the platform, runs it with the right permissions, and gets a CSV file in the current directory listing what was checked and what was found. The two warnings in the readme are what a careful user should act on. The first is about the output format, since a CSV that shows garbled text in an older Excel version can be fixed by changing the script encoding setting from the UTF-8 option to the OEM one, and newer Excel versions are recommended. The second is the important one, and it concerns a specific check item.

The item that will lock you out if you configure it

The readme carries an explicit warning about one of the Linux checks, the item that verifies the limit on failed user authentication attempts, and says it should not be configured for now because doing so results in being unable to log in remotely over SSH or locally. That is a sentence worth more than any compliance feature, because it describes the classic failure of a hardening script, where a rule written for a data centre is applied to a machine an administrator is connected to through and locks them out. The detail also tells you something about the maturity of the project, since a tool that ships with a known dangerous item marked as do not configure has been used on real machines by someone who got locked out. The rest of the advice is mundane and useful, with a note that the CSV is easier to read if the columns are split on a tab key. In practice, the safe way to use a checker like this is to run it first, read the report, and then apply changes by hand to a machine you have console access to.

Running the Windows check

The Windows side is a PowerShell script, and the documented sequence is short. The first step is to relax the execution policy for the session so the script can run, the second is to run the script, and the third is to open the report that the script leaves in the current directory, which the readme names as an ip.csv file.

Set-ExecutionPolicy Unrestricted
.\windowsCheck2.1.ps1

The script name carries a version, 2.1, which is worth noting because the Windows and Linux scripts are versioned independently. The check categories for Windows are listed in a table in the readme. Account configuration covers the account lockout policy, checking the lockout time and attempt count settings. Password configuration covers the complexity policy, checking length and complexity requirements. Authorization configuration covers user permission settings and how administrator rights are assigned. Log configuration covers audit policy and system audit log configuration. Network configuration covers firewall rules, checking open ports and services. And an other category covers registry security configuration. Each entry in the report therefore maps to a specific piece of configuration on the machine, which is what makes the output usable as evidence.

Running the Linux check

The Linux side is a bash script, and the sequence is the mirror image of the Windows one, with a step for making it executable first.

chmod +x linuxcheeklist2.2.sh
./linuxcheeklist2.2.sh

The report lands in the current directory as checklist.csv, and the check categories are again given as a table. Account management covers the account lifecycle, checking account creation, deletion and disabling. Password policy covers complexity and validity periods. Authentication configuration covers SSH security and the login configuration. File permissions cover the permissions on key system files. Log auditing covers system logging and audit configuration. And service management covers unnecessary services, checking startup items and daemons. The pairing of categories with the two configuration documents is the structure that makes the tool usable in a compliance conversation, since each check in the CSV can be traced back to a line in the baseline document for that platform.

The baseline documents are the real content

The project structure in the readme is the clearest view of how this is maintained. There is the readme, the Linux script, the Linux baseline configuration document, the Windows script and the Windows baseline configuration document. Each script has a matching document, and the two platforms are on different versions, with Linux at 2.2 and Windows at 2.1, which tells you the work is uneven and that the platform you care about may be behind. The technical stack section names the same set of technologies in four lines, PowerShell for the Windows script, bash for the Linux script, CSV for the report format and Microsoft Word for the configuration documents. The Word documents are the part that will irritate a Linux shop and that will reassure an auditor, and they are the reason the tool can be used to show a standard rather than a set of ad hoc checks. If your organisation has its own baseline, the sensible approach is to use these documents as a template and write your own checks against them, since the scripts are hand written and therefore readable.

Where this fits in a compliance process

The readme lists five situations the tool is aimed at, and they describe a cycle rather than a one-off. The first is system security compliance checking, specifically the classified protection scheme that Chinese organisations use, the second is server hardening for a machine that is about to go live, the third is periodic security auditing, the fourth is verifying that hardening measures actually took effect, and the fifth is using it as a teaching aid for administrators. The fourth use is the one that makes the CSV format worth having, because the same check list run before and after a change gives you a diff of what you fixed. The features list adds the dimensions the tool covers, accounts, passwords, authorization, logs and network communication, along with automated execution, a standard CSV checklist for analysis and archiving, cross platform support, hand written code that is easy to read and develop further, and a configuration document for different scenarios. The update log records the current versions as an improvement to the check logic and accuracy, new check items, a better report format and fixes for known issues, and a note that the readme itself was redesigned on 2026-04-01.

Licence metadata and a project without releases

The readme states that the project is open source under the MIT licence and points at a licence file, while the repository listing at the level of this task reports the licence as unknown with a custom classification that GitHub cannot parse, so the licence file is the document to read. The top level listing also shows the licence file is not present under that name, which is consistent with a project that moved its assets around and left the metadata behind. The other structural point is the absence of releases. There are no GitHub tags or GitHub releases listed, so the versions live in the script filenames, 2.1 for Windows and 2.2 for Linux, and in the update log in the readme. That is workable for a tool you clone or download directly, and it is a reminder that the version you are running is the one in the filename, not one a package manager can resolve for you. The last push was on 2026-04-03, and the contact details are the issue tracker and a GitHub profile link rather than a dedicated support channel.

Editorial conclusion

Baseline-check earns its place for an administrator who has to demonstrate a security baseline to an auditor and needs evidence rather than a screenshot, since the output is a CSV checklist of items rather than a pass or fail, and the per-platform configuration documents mean the baseline is written down rather than living in a script. It is the wrong tool if you need remediation rather than detection, since the scripts check and report, and the wrong tool for a platform other than Windows and Linux. Verify three things before you run it on a machine that matters: that you have read the warning about the authentication failure limit item, because configuring it wrongly prevents remote SSH and local logins, that you can open the generated CSV in the tool your organisation uses, since the readme calls out an encoding problem with older Excel versions and suggests a tab separated view for reading, and whether the baseline document in the repository matches the rules your own policy requires, since a compliance tool is only as good as the standard it encodes. The readme states the project is MIT licensed with the terms in the licence file, the last push was on 2026-04-03, and the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. README
3. tangjie1/-Baseline-check on GitHub