interface Control {
  owner: 'product-sec';
  implemented: true;
  evidence: 'sast-08';
}

const gap = (c) => {
  return !c.evidence;
};

async function run() {
  await assess();
  await gaps.find();
  await implement();
  await validate();
}

// evidence, on request
const proof = attest();

Application & AI Security · Software Security Assurance · Security 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.

Assess Your Software Security Program Review a Product or AI System

How the Work Fits Together

One System, Three Practices

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.

Is the software secure?

Application & AI Security

Find and reduce risk in the software itself.

Application Security Assessments
AI and LLM Security Reviews
Penetration Testing
Threat Modeling
and 4 more

Explore Application & AI Security

Can you prove it?

Software Security Assurance

Build a defensible software-security program and prove that it operates.

Evidence Readiness Assessment
Secure Development Program Assessment
Secure SDLC Program Design
NIST SSDF Readiness
and 10 more

Explore Software Security Assurance

Who builds the fix?

Security Engineering

Turn security recommendations into working controls.

DevSecOps Implementation
CI/CD Security
Security Automation
Remediation Engineering
and 6 more

Explore Security Engineering

Flagship Assessment

Can you prove how your software is secured?

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.

Discuss an Assessment

Selected Engagement

What the Work Actually Looks Like

Anonymized at the client’s request. Sector and scale are indicative, findings are described without identifying the system.

Insurance · Mid-market Software Security Assurance

From nothing in place to a program the regulator passed

Regulator reviewed the program and passed it

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.

See all four engagements

Standards Participation

717 DEV holds voting membership in INCITS, the ANSI-accredited body for US information technology standards. Founder Matthew Houseman serves as editor of ISO/IEC PWI 26688, Application Security Market Analysis.*

OWASP Leadership

Founder Matthew Houseman is an OWASP Harrisburg Chapter Leader and chairs the OWASP ISO Liaison Working Group. Our assessments draw on the open OWASP projects that work sits alongside.*

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.

A free 30 to 45 minute scoping call, no NDA required. Most inquiries get a quick reply.

Reach us directly.

Tell us what you're working on. Most inquiries receive a quick response.

Email info@717dev.com Phone 717.856.7486 LinkedIn Matthew Houseman

Name

Phone Optional

I'm Exploring

Message