Application & AI Security · Software Security Assurance · Security EngineeringApplication & AI · Assurance · Engineering
Software security you can build, test, and prove.
717 DEV helps software organizations secure applications and AI systems, operationalize secure development, and produce defensible evidence for customers, regulators, and leadership.
Plenty of firms will test your application and hand you a PDF. We assess the software and the program that produced it, then stay to build the fixes and confirm they hold.
Step 01
Assess
Test the product and examine the program behind it: architecture, code, pipelines, ownership, and the evidence sitting behind each control.
Step 02
Identify Gaps
Separate what is missing from what exists but cannot be demonstrated. Both are gaps, and they need different fixes.
Step 03
Implement
Build the controls, automation, and architecture changes. Engineering work in your stack, not a list of recommendations.
Step 04
Validate
Re-test, re-examine, and confirm the control operates. A gap closes on evidence, not on assertion.
Findings feed the program view. The program view sets the build order. What gets built comes back for validation.
Core Practices
Three Practices, One Company
Each answers a different question. Together they cover the software, the program that builds it, and the work of fixing both.
Owning security tools is not the same as running a program, and running a program is not the same as being able to show it. The second thing is what gets asked for, usually on a deadline, usually by someone who can hold up a deal.
Enterprise customers
Regulators
Government purchasers
Executives
Boards
Auditors
Business partners
The Software Security Evidence Readiness Assessment examines how your organization governs, performs, and evidences software security across roughly thirty areas, from threat modeling and secure coding through SBOM processes, release integrity, and vulnerability disclosure. You get a scored picture, a gap analysis mapped to public frameworks, and a roadmap sequenced to the work required.
Anonymized at the client’s request. Sector and scale are indicative, findings are described without identifying the system.
Insurance · Mid-marketSoftware Security Assurance
From nothing in place to a program the regulator passed
Trigger
A state insurance cybersecurity regulation required a documented security program, evidence that it operated, and a commitment to ongoing assessment. They had none of the three, against a fixed compliance date.
What we found
No secure development process, no application security testing, and no view of the software supply chain. Tooling was deployed but not configured to cover what the regulation required, and nothing was written down behind any of it. The gap was not spend. Nothing was documented, owned, or verifiable.
What changed
We built the program from the ground up: secure development, application security and penetration testing, and software supply-chain coverage, along with the tooling to support them, reconfiguring what they already owned before specifying anything new. Policies, procedures, and named ownership followed, with internal assessment running before the deadline rather than after it. The regulator reviewed the program and passed it.
Founder Matthew Houseman serves as editor of ISO/IEC PWI 26688, Application Security Market Analysis. 717 DEV is independent and is not endorsed by any standards body.
OWASP Community
Work in the OWASP community on application and AI security, alongside the open projects our assessments draw on.
Get in Touch
Start a Conversation
Whether you are scoping an assessment, preparing for a customer security review, or trying to work out where the gaps are, tell us what you are dealing with.
Reach us directly.
Tell us what you're working on. Most inquiries receive a response within one business day.
