SICEKIT is built on MediaWiki, so hardening must combine CMDB data governance with MediaWiki platform security practices.
SICEKIT security inherits MediaWiki security posture.
Required controls:
- keep MediaWiki and all enabled extensions patched
- restrict
LocalSettings.php permissions to root/web admin only
- disable anonymous editing for CMDB namespaces
SICEKIT relies on wiki templates/forms for CI modeling. Unauthorized template edits can silently corrupt inventory quality.
Controls:
- lock CMDB template categories to admin/editor groups only
- separate contributor and approver roles for schema-like page changes
- watchlist and alert on changes to core CMDB templates/forms
¶ 3) Harden API and bot account usage
MediaWiki API access is often used for imports and automation.
Integration controls:
- use dedicated bot/service accounts with limited rights
- avoid using personal admin accounts for automation tokens
- rate-limit and monitor API write activity for bulk edit anomalies
¶ 4) Restrict file upload and executable content risk
Wiki attachments can become malware delivery paths if upload policy is weak.
Upload controls:
- limit allowed MIME types/extensions to documentation formats only
- disable execution of uploaded files at web server level
- scan uploads with malware detection before publishing
¶ 5) Compensate for project maintenance risk
SICEKIT is repository-driven and operators should verify maintenance state continuously.
Operational controls:
- pin extension/plugin versions and track upstream repository activity
- run periodic dependency/security scans on MediaWiki + extension stack
- maintain tested rollback and restore process for wiki DB and file store
- SICEKIT source repository: https://github.com/sicekit/sicekit
- MediaWiki hardening and security docs: https://www.mediawiki.org/wiki/Manual:Security
Any questions?
Feel free to contact us. Find all contact information on our contact page.