Start Tools Patterns Notes About Contact
Cybersecurity Engineering · St. Augustine, FL

David R. Gillispie

Security engineering you can inspect.

Cybersecurity engineer working across application security, AI security, cloud security, identity and access management, vulnerability management, and penetration testing.

A public proof layer: tools, patterns, notes, and public-safe examples built without exposing employer data, client details, or NDA-protected work.

Domain Security Scanner ↗ open tool
22
Free security tools in the lab
10
Engineering patterns, documented
72%
Enterprise vulnerability reduction, past engagement
What you will find here

Four ways to see how I work.

LAB / 01
Security Lab

Public-safe utilities that make security checks and workflows you can actually inspect. Not employer tools, not client work.

Explore the lab →
PAT / 02
Engineering Patterns

How I harden systems, reduce exposure, design controls, and turn risk into fixable work without exposing any private environment details.

Browse patterns →
NOT / 03
Field Notes

Short writing on cloud security, identity, AI tool risk, vulnerability workflows, and practical remediation from real engineering work.

Read the notes →
RES / 04
Resume Context

A sanitized professional summary covering background, certifications, and focus areas. No internal metrics, no private environment details.

View resume →
Security Engineering Tools

Decision-support tools for real security work.

Four tools for vulnerability prioritization, identity risk mapping, AI workflow review, and security architecture planning. Each started as a checklist or spreadsheet. These are the formalized versions.

Flagship · Identity Security
Identity Risk Mapper

Walk through M365 and Entra ID controls, answer yes or no, and get a scored breakdown with specific findings. Built from the same checklist I use in identity security reviews.

Launch Tool →
Vulnerability Management
Vulnerability Prioritization Engine

CVSS alone misses context. Add whether the system is internet-facing, whether a public exploit exists, and what data is at risk. Score adjusts accordingly.

Launch Tool →
AI Governance
AI Workflow Risk Reviewer

Describe any AI-enabled workflow in plain text and get a risk analysis: data exposure, third-party AI risks, governance gaps, and recommended controls.

Launch Tool →
Architecture · Cloud Security
Security Architecture Generator

Generate a practical security architecture based on company size, platform, work model, data sensitivity, and compliance needs. Includes a 30-day priority plan.

Launch Tool →

Everything runs in your browser. Nothing is sent anywhere.

Security Lab

Tools that make the work inspectable.

Small, public-safe utilities. Each one reflects a real security concept you can run in a browser without sending data to any private system.

Open the full lab →
Latest Notes

How I think through it.

Read all 12 notes →
Engineering patterns

Public-safe engineering work.

Generalized patterns showing how I move from risk signal to design decision, fix path, validation, and repeatable control.

Browse all 10 patterns →
How I work

Engineering is the outcome, not the report.

I care about what happens after risk is found: the fix, the rollout, the validation, and the repeatable control.

01
Understand the system

Know what exists, who owns it, what data it touches, and what should not change before recommending anything.

02
Find the risky path

Map how risk actually travels: through identity, SaaS permissions, cloud configuration, or external exposure.

03
Validate what is real

Scanner output is a starting point. Validate each finding against the actual environment before it becomes a remediation item.

04
Design the change

Reduce exposure without creating new problems. Think through rollout risk, rollback options, and sign-off before implementation.

05
Make it usable

Findings become owner-ready tickets with specific steps, one owner, a definition of done, and retest criteria.

06
Verify and document

Retesting proves the fix. Documentation makes the improvement repeatable. Closure means the finding is actually gone.

Read the full methodology →
Where it started

I was interested in systems because I wanted to know how they broke.

As a kid, I took apart the family computer, learned Windows when the internet was off, wrote small batch scripts, and tried to understand how admin controls actually worked. I was not just interested in using computers. I was interested in making them do things, finding limits, bypassing restrictions, and figuring out why something failed.

One early lesson came from a screen-time control device connected to our TV. My stepdad kept changing the PIN because I kept figuring it out. What I was really doing was listening to the keypad tones, memorizing the pattern, and mapping the sounds back to numbers. At the time, I just wanted more video game time. Looking back, it was the same mindset that pulled me toward penetration testing later: observe the system, find the weak point, test the assumption, and understand the failure.

Cybersecurity gave that curiosity a responsible direction.

Full story on the about page →
Age 6–10
Took apart computers. Learned Windows, hardware, and software. Broke things, fixed them, tried again.
Early lesson
Controls fail when the surrounding process is predictable. The weakness was never the device. It was the behavior around it.
Age 12
Knew technology was the direction. Penetration testing gave structure to the curiosity about how things fail.
Today
Security engineering, public-safe tools, engineering patterns, and practical fixes.
David R. Gillispie
About

Security engineer, founder, and instructor.

Cybersecurity engineer working across application security, AI security, cloud security, identity and access management, vulnerability management, and penetration testing. I currently lead internal AI security and penetration testing programs while running consulting engagements through DeepDream Security.

I also teach networking and cybersecurity as an adjunct instructor, which sharpens how I explain technical risk to non-security audiences.

Consulting

When the work is consulting-focused, I route it through DeepDream Security.

External exposure reviews, web application security assessments, AI security reviews, Microsoft 365 hardening, and remediation planning for small and mid-size businesses.

Visit DeepDream Security ↗
Public-safe by design

Built to show the work without crossing trust boundaries.

No employer data, client data, internal screenshots, private dashboards, exploit evidence, or NDA-protected details. Everything uses mock data, generalized patterns, and public-safe tooling.

No client dataNo internal screenshotsNo private dashboardsNo NDA detailsNo exploit evidenceNo fake metrics
Contact

Get in touch.

Routing by intent: consulting, career, email, and Upwork.