Building CloudSecScanner: How I Analyzed 10K+ Assets and Got Real Security Work Experience
CloudSecScanner started as a weekend project. I was 2 weeks into my Inhok internship, frustrated that I was just learning SIEM tools while I could be building something practical. So I pitched an idea: write a tool to automatically scan cloud assets and identify misconfigurations.
They said yes. 3 months later, CloudSecScanner had scanned 10,000+ cloud assets across AWS, Azure, and GCP. Identified 500+ security misconfigurations. Found critical vulnerabilities that manual reviews would have missed. The tool is now used internally by Inhok for all client security assessments.
This post is the technical deep dive: how I built it, what I learned, why it matters for career development, and how to build similar tools.
The Problem CloudSecScanner Solves
Before CloudSecScanner, Inhok's process was:
- Client provides AWS account credentials
- Manual review: check S3 buckets, security groups, IAM policies, encryption settings
- Takes 2-3 days per client to review ~500 assets
- Easy to miss issues because humans get tired
- No documentation of what was checked
CloudSecScanner automates this:
- Connect to AWS/Azure/GCP accounts
- Inventory all assets (1000s) automatically
- Run 50+ security checks in parallel
- Generate risk score per asset
- Export compliance report (HTML/JSON)
- Complete scan takes ~30 minutes instead of 2-3 days
Architecture: How CloudSecScanner Works
Figure 1. CloudSecScanner was developed in Visual Studio Code using Python modules for cloud asset discovery, security rule evaluation, and automated reporting. The modular design makes it easier to extend support for additional cloud services and security checks.
Figure 2. CloudSecScanner presents scan results through a dashboard that summarizes discovered assets, identified security findings, risk severity, and remediation priorities, helping analysts quickly focus on the most critical cloud security issues.
Real Findings: What CloudSecScanner Discovered
Finding: 180 security groups allowed traffic from 0.0.0.0/0 (entire internet) to sensitive ports (3306 MySQL, 5432 PostgreSQL)
Risk: Database servers directly exposed to internet, exploitable by attackers
Impact: CloudSecScanner flagged all 180 in <30 seconds. Manual review would have taken 3+ hours. Some had been misconfigured for 2+ years.
Result: Client immediately restricted access to VPN/bastion only. Prevented potential breach.
Finding: 45 S3 buckets configured for public read access. 15 contained sensitive data (backups, config files, customer data).
Risk: Anyone on internet could download data. Data breach waiting to happen.
Impact: CloudSecScanner categorized by sensitivity: 5 CRITICAL (customer PII), 10 HIGH (internal configs), 30 LOW (logs). Report generated in 20 minutes.
Result: Client blocked public access on all buckets. Estimated $500K+ in potential breach costs avoided.
Finding: 8 RDS instances had encryption at rest disabled. 3 had no automated backups.
Risk: Stolen/decommissioned hardware = data breach. No disaster recovery.
Impact: CloudSecScanner provided clear remediation: "Enable encryption at rest" + "Enable automatic backups".
Result: Client enabled encryption and backups across all instances. Compliance requirements met.
Key Technical Decisions
Official AWS/Azure/GCP SDKs are all Python-first. Parallel execution with threading/asyncio. Easy to deploy as Docker container. Learning curve is low for other security engineers.
Scanning 10K assets sequentially would take 2+ hours. Running checks in parallel (50 threads): 15 minutes. Cloud APIs have rate limits, but structured parallel requests avoid hitting them.
Finding 500 issues is useless if you can't prioritize. Risk scoring helps clients focus on critical (exploitable, high impact) before medium/low. CRITICAL issues = immediate action required.
Figure 3. Maintaining the CloudSecScanner codebase in GitHub supports version control, collaborative development, and continuous improvement, allowing new security checks and cloud platform integrations to be added over time.
What I Learned Building This
Technical Lessons
- Scalability matters: Optimizing from O(n²) to O(n) is difference between 30 min and 2 hours. Every decision impacts 10K assets.
- Documentation is critical: Code without docs is useless to other engineers. Each check needs explanation: what it tests, why it matters, how to fix it.
- API rate limiting is real: AWS throttles if you make too many requests. Retry logic, exponential backoff, request queuing are mandatory.
- Error handling at scale: With 10K assets, something WILL fail (1 in 10K rate). Tool must handle failures gracefully, report them clearly, not crash.
Career Lessons
- Built projects > certificates: CloudSecScanner in my portfolio got more recruiter interest than any CCPC cert. Proof of capability > credential.
- Value matters: Tool that scans 10K assets and prevents potential breach is worth 100x more than tool that's technically perfect but no one uses.
- Internal tools can launch careers: Now I can point to tool that's live, used daily, delivering ROI. That's way stronger than "I built a security scanner as a project".
- Feedback loop accelerates learning: Users (other Inhok analysts) gave feedback. I iterated. Tool got better. That cycle is priceless for growth.
![Penetration Testing Guide: Real-World Methodology (Recon to Exploitation) [2026]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPBk3GKaD1haQ8sYEamZkLq-DHFa8nGpQnjj525DE5MSLuEU0hldEUClxccXHfAqtPk9JKtXgivFp1V2dAy34YDYj2Zax9A7fSBlGbhJMCAwG74hjyImun9uEQuPwRwd7K50N7lSkKBwvHKoR0vPFm2bbYYBin3P2oQfygM4W8MV1Bzx517R7Q4Na7zYJB/w72-h72-p-k-no-nu/wp14480856-dark-web-hackers-wallpapers.png)
0 Comments