Flagship / Open Source XDR
PublicAegis Fortress XDR
Open-source, kernel-native XDR concept for critical infrastructure, combining endpoint, network, cloud, identity, detection, SOAR, and deception layers in one documented architecture.
Case File 04 — Work
Projects, engineering practice, and the thinking behind the build.
My portfolio includes product work, defensive security systems, kernel research, open-source experimentation, and the structured methodology I use when evaluating a system under realistic conditions.
Project Index / 2026
A working archive, not a polished highlight reel.
Filter the archive by the type of work that interests you. Each entry links to a more detailed case study, a live product, or the public repository where the work is documented in context.
Showing all 12 projects
GitHub Shelf
These repositories reflect the kinds of systems I am actively exploring: defensive engineering, kernel-level security research, eBPF experimentation, and honest project work that is still evolving as I learn and improve it.
Kernel Research
PublicAether-Apex Kernel Research
Linux kernel module research exploring Ring 0 stealth mechanics, VFS and network visibility manipulation, symbol resolution, and the forensic signals defenders can use to detect them.
Kernel-Native EDR
PublicLyncis-EDR
eBPF-LSM endpoint defense focused on deterministic pre-execution enforcement, process lineage reconstruction, and automated forensic stasis after a policy violation.
eBPF / Rust EDR Agent
PublicTartarus-EDR
Linux EDR agent using eBPF tracepoints and a Rust control plane to monitor sensitive file access, intervene on violations, and send real-time telemetry.
Autonomous Defense Lab
PublicCerberus-EDR
eBPF-LSM EDR research combining kernel-enforced blocking, automated containment, a Streamlit SOC dashboard, remote telemetry collection, and a chaos-testing suite.
New Repository
Setupsentinel-vault
A newly created public repository currently without committed files. Kept visible as a transparent placeholder for the next security project.
Featured Projects
The two current flagship repositories: one broad defensive platform and one focused kernel-native enforcement system.
Flagship Security Platform
PublicAegis Fortress XDR
An open-source XDR architecture for critical infrastructure, spanning kernel-native endpoint visibility, industrial network telemetry, cloud and identity logs, AI-assisted detection, SOAR response, and deception technology.
Kernel-Native Endpoint Defense
PublicLyncis-EDR
An eBPF-LSM EDR system designed to stop unauthorized execution at the Linux kernel boundary, reconstruct process lineage, and preserve forensic artifacts through a veto–freeze–carve workflow.
Full-Stack Developer
ShippedLifeFin
Financial management platform for micro, small, and medium enterprises, focused on data handling practices and a clean, accessible interface for non-technical owners.
Self-Built, Deliberately Vulnerable API
ShippedAPI Pentesting Lab
A hands-on environment simulating real-world vulnerability classes, including IDOR, broken authentication, and injection points, built to refine testing methodology in a controlled sandbox.
Personal Tooling, Early Stage
In ProgressRecon Automation Toolkit
A toolkit automating the initial reconnaissance phase of security testing, focused on subdomain enumeration and endpoint discovery. Built as the primary vehicle for learning Go.
Reference Implementation
ShippedFirebase Auth Demo
Authentication using React and Firebase Auth, implementing email verification and secure session handling. Used as a reference for smaller projects that do not warrant a fully custom auth layer.
Case Study
C-Pay: closed-loop payment architecture, from problem to honest scope.
The Problem
Cash reconciliation had no audit trail
Campus events at my university handled payments with cash, which created two recurring issues: reconciliation errors at the end of each event, and no audit trail when disputes came up about what a student had or had not paid. C-Pay replaces that with a closed-loop digital wallet system specific to campus events.
System Architecture
Three layers, one audited write path
+------------------------------------------------------------+
| CLIENT (React) |
| Event Check-in UI . Wallet Balance View . Merchant Terminal |
+---------------------------+----------------------------------+
| HTTPS / REST
+---------------------------v----------------------------------+
| API LAYER (Express.js / Node.js) |
| Auth Middleware | Transaction Controller | Input |
| (session/token) | | Validation |
+---------------------------+----------------------------------+
|
+---------------------------v----------------------------------+
| DATABASE (MongoDB) |
| Users/Wallets Collection . Transactions Ledger . Event Data |
+------------------------------------------------------------+
Design Decisions
Four decisions and the reasoning behind them
- IsolationTransaction logic isolated from the controller layer, so balance changes can only happen through one audited code path. Any new route goes through the same function, meaning the same validation and logging apply every time. The cost is some development speed, a trade-off worth it for a system handling money.
- OwnershipEvery mutating request re-validates ownership server-side, a direct response to how easily IDOR bugs slip into naive "user owns this record" checks that trust a request parameter without verifying it against the authenticated session.
- SchemaMongoDB was chosen for flexible event and transaction schemas, since campus events have varying metadata needs and a document model avoided constant schema migrations mid-build. In hindsight, a hybrid approach with PostgreSQL for the transaction ledger might give stronger consistency guarantees.
- AuthSession-based tokens were chosen over pure JWT mainly for simpler revocation during the event itself, since killing a session immediately if a device was lost mattered more than the statelessness benefits of JWT here.
What I'd Change
Two concrete next steps
Add automated integration tests around the transaction controller specifically, since that is the highest-consequence code path and currently relies on manual testing before each deployment. Add rate limiting on the transaction endpoints, which was not implemented in the first version.
Honest Scope Note
A student project, stated as one
C-Pay was built and used for campus events, not deployed as a commercial payment processor and not handling real-world transaction volume at scale. What it demonstrates is the ability to own a complete system, including the security-conscious decisions above, from schema to shipped product.
Security Methodology
A repeatable five-step process, developed through the university-recognized assessment and a self-built pentesting lab.
- 01 ReconEnumerate subdomains, live hosts, and historical endpoints using Subfinder, Amass, Gau, and Waybackurls to build a full picture of the attack surface. The goal here is coverage, not depth.
- 02 MappingWalk the mapped surface to understand application logic: authentication flows, role boundaries, API structure, and where user-controlled input meets business logic.
- 03 ExploitationFocused manual testing against high-risk classes, primarily IDOR and authentication bypass, alongside the broader OWASP Top 10. Access control issues tend to have the clearest, most demonstrable impact.
- 04 ValidationEvery finding is retested to confirm real, reproducible impact. Theoretical or unconfirmed issues are not included in a final report.
- 05 ReportFindings are documented with clear reproduction steps and concrete mitigation guidance, plus a severity rationale, so a developer can act on them directly.
This methodology was directly responsible for the VAPT Excellence Award from Universitas Siber Indonesia, awarded for a security evaluation of live university digital assets.
Code Sample
Ownership-checked, fail-closed middleware, a representative pattern used across C-Pay to prevent IDOR on wallet and transaction routes.
// middleware/verifyOwnership.js
const verifyOwnership = (Model, paramField = 'id') => {
return async (req, res, next) => {
try {
const resource = await Model.findById(req.params[paramField]);
if (!resource) {
return res.status(404).json({ error: 'Resource not found' });
}
// Fail closed: only the authenticated owner may proceed
if (resource.userId.toString() !== req.user.id.toString()) {
return res.status(403).json({ error: 'Forbidden' });
}
req.resource = resource;
next();
} catch (err) {
next(err);
}
};
};
module.exports = verifyOwnership;