Findings out of spreadsheets
A vulnerability assessment team whose bottleneck was not finding problems. It was everything that happened to a finding afterward.
- Client
- American Systems
- Sector
- Defense, DoD contract
- Role
- Software engineer, Secret clearance
- Year
- 2016-2019
- Stack
- Python, Django
- Result
- Pipeline automated
The problem
The team assessed vulnerabilities in fielded defense systems, the kind with radar and tracks on them. When that work is wrong, the consequence is not a bad quarter, and everyone involved knows it.
The analysis was the part the team was good at. The rest of it was spreadsheets. Findings lived in files that lived on machines, and the customer deliverable was assembled by hand from whatever those files said that week. The engineering problem was not detection. It was that a finding took longer to travel than to discover.
The constraint
In this environment software is approved, not installed. Anything I built had to pass a review process before it could touch real data, which rules out most of the reflexes a developer brings from commercial work. No reaching for a hosted service, no adding a dependency because it would save an afternoon.
The second constraint was that the team could not stop assessing while I built. The tooling had to absorb the existing way of working rather than demand a new one, because a process that requires everyone to change on a Monday does not survive to Tuesday.
What I built
One place for a finding to live
A Django application that became the system of record, replacing the spreadsheets that had been holding the team's work. A finding was entered once and stayed addressable afterward, which sounds obvious and was not the situation before.
The pipeline between the tools and the record
Python moving vulnerability data from where it was produced into that one shape, so the transcription work that had been done by people stopped being done by people. The team's hours went back to analysis, which is what they were there for.
The deliverable, generated
The customer report assembled itself from the data instead of from somebody's afternoon. Generating the artifact from the record also meant the record had to be right, which quietly raised the standard on everything upstream of it.
Result
Findings stopped living in files on machines and started living in one system the whole team worked from.
The report came out of the data rather than out of a manual assembly step at the end of each cycle.
It cleared the review process and ran against actual assessment work, which in this environment is the result that counts.
The resume figures for this engagement (20% fewer security incidents, 35% faster assessments) were identified as estimates and are deliberately absent. What is claimed here is what the system replaced, not what it improved by.
What I would change
I planned the engineering and assumed the rest would follow it. In a controlled environment the schedule is not set by how fast you write the code; it is set by accreditation, documentation, and the people who have to sign. I treated that as overhead attached to the end of the work rather than as the work, and the plan I gave reflected the wrong one.
What I would do now is map the approval path before writing the first line, and get the requirements for it in writing from whoever owns the decision. Not because the process is agreeable, but because in that environment the review is the delivery date, and knowing it early changes what you build first.
Email me
If you are hiring for a senior full stack or frontend role, a line about the team and the stack is enough to start.