Can you prove how your software is secured?
A structured assessment of how your organization governs, performs, and evidences software security, scored, mapped to public frameworks, and delivered with a roadmap you can fund.
Discuss an AssessmentThe question arrives on someone else's timeline
A prospect's security team sends a sixty-question review with a deadline attached to a deal. A federal purchaser asks for an attestation on secure development practices. A board member reads about a supply-chain compromise and asks whether it could happen here.
None of these ask whether you own security tools. They ask whether you run a program, and whether you can show it. Most organizations discover the gap between those two things while under time pressure, which is the worst moment to find out that the answer lives in four people's heads and a spreadsheet nobody has opened since the last audit.
The Audiences That Want Evidence
Commercial and regulatory
- Enterprise customers running vendor security reviews
- Regulators with software-security expectations in scope
- Government purchasers requiring secure development attestations
- Business partners flowing requirements down their supply chain
Internal and financial
- Executives who need a defensible account of software risk
- Boards asking questions that require data, not reassurance
- Auditors testing whether controls operate as described
- Investors and acquirers treating product security as operational risk
What the Assessment Evaluates
Roughly thirty areas, grouped into seven themes. Each is assessed three ways: what is documented, what is actually performed, and what can be evidenced on request.
| Theme | Areas assessed | What we are establishing |
|---|---|---|
| Governance and ownership | Software-security governance; security ownership and accountability; risk acceptance; management review; continuous improvement | Who decides, on what basis, and where that decision is recorded |
| Secure development practice | Secure development requirements; threat modeling; security architecture; secure coding practices; developer security enablement | Whether the practices are performed across teams or only on the flagship service |
| Testing and tooling | SAST; DAST; SCA; secrets scanning; IaC scanning | Coverage, tuning, and whether findings reach someone who acts on them |
| Pipeline and release | CI/CD security; release security; code signing; release integrity | What can reach production, through which path, with whose approval |
| Vulnerability handling | Vulnerability triage; remediation processes; product security incident response; vulnerability disclosure | Consistency of treatment and time to closure by severity |
| Supply chain | Software supply-chain security; SBOM processes; supplier security; third-party software assurance | What you depend on, how you know, and what happens when an advisory lands |
| Measurement and evidence | Metrics; security evidence management | Whether the evidence exists, is current, and can be produced on request |
Note: a control that exists but cannot be demonstrated is recorded separately from a control that does not exist. The two need different work, and conflating them is how remediation budgets get spent in the wrong place.
What You Receive
- Executive maturity scorecard giving a per-theme score and an overall picture leadership can read in one page
- Detailed findings report covering every area assessed, with what was examined and what was concluded
- Software-security evidence inventory listing what evidence exists, where it lives, who owns it, and how current it is
- Gap analysis separating missing controls from undemonstrable ones
- Public-framework mappings showing where you stand against the frameworks relevant to your obligations
- Prioritized remediation recommendations ordered by risk reduction per unit of effort
- Sequenced implementation roadmap with dependencies and rough effort made explicit. Larger estates are sequenced over multiple years; the horizon follows the work required and the resources available to do it
- Executive presentation delivered live to the audience that needs to approve the work
Applicable Public Frameworks
Findings are mapped to published, publicly available frameworks so the results connect to something your customers and regulators already recognize. Which mappings apply depends on your market and obligations, and we agree that during scoping.
- NIST Secure Software Development Framework (SSDF, SP 800-218)
- OWASP SAMM for software assurance maturity by stream
- OWASP ASVS where application-level verification requirements are in scope
- CISA Secure by Design principles and product-security expectations
- Relevant published ISO/IEC standards covering application and software security
- Applicable software-security regulations for the markets you sell into
What this engagement is: an independent assessment performed by 717 DEV, mapped to public frameworks, delivered as advice to your organization.
What it is not: a certification, a formal audit, a regulatory attestation, or an accredited conformity assessment. 717 DEV is not a certification body and does not issue certificates. Being assessed by us does not make your organization certified, compliant, or approved against any standard, and no standards body endorses or accredits this engagement. Where a formal certification or audit is required, we can help you prepare for it, but the certificate comes from an accredited body, not from us.
717 DEV is not a law firm and does not provide legal advice. Whether a particular regulation applies to your organization is a question for your counsel.
Discover, Evaluate, Roadmap, Validate
The assurance engagement model. Duration depends on the size of the estate and the number of teams in scope, and we agree it during scoping rather than quoting a number here.
Establish what the program is meant to be before assessing whether it is.
What we do
- Review existing policies, standards, and prior assessment work
- Map the delivery landscape: teams, repositories, pipelines, and release paths
- Identify the stated owner for each area under assessment
- Agree the sample of services and releases we will examine in depth
What we need from you
- Access to documentation, pipelines, and finding queues (read access is usually enough)
- Introductions to the engineering and security leads for the sampled services
- Any customer questionnaire or regulatory requirement driving the timeline
Assess each area against what is documented, what is performed, and what can be evidenced.
What we do
- Structured interviews with engineering, security, and product owners
- Direct examination of pipelines, tool configurations, and finding queues
- Trace a sample of vulnerabilities from discovery through to closure
- Trace a sample of releases through the gates that were supposed to apply
- Separate control gaps from evidence gaps, because they are fixed differently
What we need from you
- Roughly one hour per interview, from the people who actually do the work
- Read access to a representative sample of build and release records
- A named point of contact to resolve access questions quickly
Turn the findings into a sequence somebody can fund and staff.
What we do
- Map findings to the public frameworks relevant to your obligations
- Prioritize by risk reduction per unit of effort, not by framework order
- Sequence work across twelve months with dependencies made explicit
- Draft the executive narrative for the audience that has to approve it
What you will see
- A draft report circulated for factual accuracy before it is finalized
- A working session on prioritization, so the sequence reflects your constraints
- The executive presentation, delivered to whichever audience needs it
Confirm that what was built actually operates.
What we do
- Re-examine the areas addressed since the assessment
- Sample releases and findings again to test consistency, not intent
- Attempt the bypass paths where a gate is meant to block
- Record residual and accepted risk in writing, with the accepting owner named
What you will see
- A validation report stating, per area, whether the control now operates
- An updated evidence inventory reflecting the current state
- A clear statement of what remains open and who accepted it
What Happens Once Gaps Are Identified
The roadmap exists to be executed. You can run it with your own team and bring us back for the validation pass, or we can do the engineering. Both happen.
Find out what you can actually prove
Tell us what prompted the question: a customer review, an attestation deadline, or a board asking something nobody could answer. Scoping starts from there.
Discuss an Assessment