Portfolio Code Repository Audit — 2026-06-23

Purpose

This document records a source-level audit of the main portfolio repositories and turns the findings into a calibrated improvement backlog.

The audit focuses on whether the repositories demonstrate real technical structure, operational thinking, governance boundaries and validation evidence.

The purpose is not to claim production maturity. The purpose is to preserve a realistic view of the portfolio's technical strengths, risks and next development steps.

Scope

The audit covered the following portfolio areas:

• Gatehouse / Infrastructure Change Quality Gate
• RBAC-Lite
• Local-First WordPress DevSecOps Kit
• ESP32 IoT Security Governance Lab
• GitHub profile and portfolio presentation

The review was based on source-level inspection of repository files, workflows, Docker Compose configuration, validation scripts, plugin code, firmware skeletons and documentation.

This audit did not include full local execution of every workflow, Docker runtime, pytest suite or PlatformIO build in the review environment.

High-level result

The portfolio does not look like a toy or copy-paste-only collection.

The strongest shared signal is:

scope control + validation + evidence + governance + public/private boundary + operational thinking

A realistic overall calibration for the Finnish market:

8.2 / 10 as a mid-level technical portfolio baseline

The strongest value is not the amount of code alone. The strongest value is the operating model around the code:

• documentation
• reviewability
• recoverability
• controlled change
• public-safe evidence
• CI/CD and validation thinking
• explicit boundaries around what not to claim

Main risk

The main risk is not that the repositories are empty.

The main risk is that some CI/security badges or checks may look stronger than they technically are, especially when checks are advisory or non-blocking.

This should be handled by clearer wording:

advisory security scanning

instead of implying:

hard blocking security gate

unless the workflow really fails the build on that condition.

1. Gatehouse / Infrastructure Change Quality Gate

Strengths

Gatehouse remains the strongest repository in the portfolio.

Strong signals:

• legacy wrapper delegates to modular CLI instead of duplicating logic
• CLI is sensibly split into config, parser, reporter and rules
• risk class, rollback, approvals, freeze and test plan are treated as governance controls
• example change request is credible and scoped correctly
• risk class 2 framing is realistic for the demonstrated example
• validation and audit evidence are central to the repository purpose

Findings

Potential improvements:

1. The Markdown regex parser is useful for a portfolio quality gate, but structurally fragile.

2. Rollback strategy validation appears too permissive if a fallback pattern accepts almost any non-empty string.

3. Invalid YAML/JSON config should not silently fall back to defaults without a clear warning or failure mode.

4. Absolute paths are currently treated as warnings, but CI may benefit from stricter handling for evidence hygiene.

Calibrated conclusion

Gatehouse is a strong governance-engine reference implementation.

It should be described as:

CI quality gate for infrastructure change governance and audit evidence

not as:

production enterprise GRC platform

2. RBAC-Lite

Strengths

RBAC-Lite contains real WordPress/plugin-level security and governance thinking.

Strong signals:

• ABSPATH guard exists
• admin profile fields use nonce verification
• admin operations use capability checks
• partner IDs are sanitized
• output is escaped
• audit log uses $wpdb->insert with formats
• fail-closed user-list behavior exists when partner mapping is missing

Findings

Priority findings:

1. create_tables() should not run on every plugin load through the constructor.

- Better model: activation hook or versioned migration.

2. SHOW TABLES LIKE '$table_name' should use $wpdb->prepare().

- Risk is low because table name is derived from prefix + constant, but prepared SQL is cleaner and aligns better with WordPress standards.

3. check_nda_acceptance() appears to use wp_safe_remote_post(admin_url(...)) where a redirect-style flow may be intended.

- Server-side HTTP POST to own admin URL does not redirect the user.

- If NDA acceptance is a real flow, it should likely use wp_safe_redirect(...) and exit with a properly defined target.

4. pre_get_users may be too broad.

- It should be scoped to the intended admin screen or user-list context.

5. Capability checks could be more specific.

- manage_options is strong, but profile editing should also consider current_user_can('edit_user', $user_id) where relevant.

Calibrated conclusion

RBAC-Lite is a good portfolio baseline for access-control governance, partner isolation and audit trail thinking.

It should not be described as production-ready enterprise IAM.

3. Local-First WordPress DevSecOps Kit

Strengths

The Local-First WordPress DevSecOps Kit is a strong local development and handover baseline.

Strong signals:

• Docker Compose environment is clear
• localhost-bound ports reduce accidental exposure
• WordPress, database and mail testing are separated
• MariaDB healthcheck exists
• README frames the project as local-first, not production
• no production data boundary is explicit
• AI boundary, recoverability and auditability are part of the documentation
• CI includes compose validation, secret scan, shell lint, Python validation, environment validation, runtime checks and docs checks
• additional security workflows include tools such as Trivy, Bandit, git-secrets, license checks or composition audit style controls

Findings

Potential improvements:

1. Avoid overly broad latest image tags where possible.

- More precise image tags would better match the governance narrative.

2. Local demo passwords must remain clearly local-only.

- Defaults such as wp/wp and root/root are acceptable only in a local-only context with localhost-bound ports.

3. Non-blocking scans should be named as advisory.

- If ShellCheck, Black, TruffleHog, Bandit or git-secrets are configured not to fail the build, the documentation should call them advisory scans.

4. Docker build validation may be partly cosmetic if services use upstream images rather than custom Dockerfile build contexts.

- This is acceptable, but the claim should be phrased accurately.

Calibrated conclusion

This repository is a good local-first DevSecOps baseline.

The main improvement is wording and/or gate behavior:

advisory security scanning

versus:

blocking security gate

4. ESP32 IoT Security Governance Lab

Strengths

The ESP32 lab is technically useful and safely scoped.

Strong signals:

• firmware is a safe skeleton
• no Wi-Fi scanning
• no Bluetooth discovery
• no telemetry upload
• no OTA update claim
• public example config is explicit about avoiding credentials, customer values and environment details
• PlatformIO target is clearly defined
• readiness model is domain-neutral
• README avoids production, pentest and drone overclaims
• the repository demonstrates governance-first embedded/edge thinking instead of generic blink-demo work

Findings

Potential improvements:

1. lab_config.example.h is included directly by the firmware.

- This is acceptable for a public-safe lab, but a more production-like pattern would use lab_config.h with .example.h as a template.

2. Readiness model should validate unrealistic input ranges.

- Examples: negative battery percentage, humidity over 100 %, impossible temperature values.

3. Device identity could be validated.

- Empty or placeholder device_id values should be rejected or flagged in evidence-oriented models.

Calibrated conclusion

This is a strong embedded / edge-device governance evidence repository.

It should be framed as:

public-safe embedded governance lab

not as:

production embedded security firmware

5. GitHub profile and portfolio presentation

Strengths

The profile has a clear technical theme and supports the repository evidence.

Strong signals:

• governance and auditability are consistent themes
• DevSecOps and operational security are framed through evidence rather than slogans
• profile includes a calibration statement and does not claim full ownership of large-scale production platforms
• technical-documentation now provides a public-safe narrative layer
• the portfolio is becoming a coherent system rather than a loose collection of demos

Risks

Potential risks:

1. Too many badges may create a badge-wall effect.

2. Older or lower-signal demo repositories may distract from the strongest work.

3. Fork or template noise should remain secondary.

4. CI/CD or security badges should not imply production-grade gates if the checks are advisory.

Calibrated conclusion

The profile is strong, but future work should focus on reducing noise rather than adding more labels.

The profile should direct readers toward:

• Gatehouse
• ESP32 governance lab
• RBAC-Lite
• Local-First WordPress DevSecOps Kit
• Technical Documentation Hub

Prioritized backlog

P1 — first corrections

1. RBAC-Lite: replace the wp_safe_remote_post(...) NDA pattern with a correct redirect or user-flow model.

2. RBAC-Lite: move table creation out of the constructor into activation or versioned migration logic.

3. Local-First WordPress DevSecOps Kit: rename non-blocking security checks as advisory or make selected checks blocking.

4. Local-First WordPress DevSecOps Kit: pin image versions more precisely.

P2 — next improvements

5. Gatehouse: tighten rollback strategy validation and remove overly permissive fallback matching.

6. Gatehouse: make invalid config handling visible through warning or fail behavior.

7. ESP32 lab: add input validation for readiness models.

8. RBAC-Lite: scope pre_get_users more narrowly.

P3 — portfolio polish

9. Reduce badge-wall effect on the GitHub profile.

10. Add or strengthen a Start here path that points to the technical-documentation preview and strongest repositories.

11. Keep the main message focused on CI quality gates, governance baselines and public-safe evidence.

12. Avoid describing any reference implementation as production customer infrastructure unless that is explicitly true.

Portfolio interpretation

The audit supports the existing portfolio narrative.

The strongest signal is not graphical UI work.

The strongest signal is:

operational backbone

This means:

• governance structures
• CI/CD validation
• documentation boundaries
• evidence preservation
• local-first safety
• access-control thinking
• rollback and recovery thinking
• practical public/private separation

Final assessment

The portfolio can withstand a technical recruiter or technical interviewer reading more than the front page.

There are real issues to fix, especially around RBAC-Lite and advisory-versus-blocking CI language, but the issues are normal improvement items rather than evidence that the repositories are fake or empty.

The correct next step is not to add more repositories.

The correct next step is to make selected existing repositories sharper, more accurately worded and less cosmetically noisy.

Final calibrated summary:

The code is not production-perfect, but it is real enough to support the portfolio narrative.
The strongest evidence is not UI polish; it is documented, controlled and reviewable technical delivery.