01
Level 1
Example: A marketing site with a contact form, or an internal tool with no sensitive data
Approach: The baseline set of requirements, checked with automated tools and a focused review.
Application Security Consulting
Application security consulting for product teams
Security reviews from customers and auditors ask how your team builds software, not just whether the last test passed. Agnotic Technologies sets up a secure development lifecycle inside your delivery process and leaves the evidence those reviews ask for.
NIST SSDF mappingOWASP ASVS levelsThreat modelingPipeline checks
Trusted by global innovators
Secure development
What is application security consulting?
Application security consulting is setting up how a product team designs, builds and ships software securely. Agnotic Technologies maps your current practice to the NIST Secure Software Development Framework, picks an OWASP ASVS level per application, adds threat modeling and pipeline checks, and leaves the evidence that customer and federal security reviews ask for.
It is engineering work inside your delivery process. We do not run a company-wide security program or ISO 27001 certification, and Agnotic does not certify your product.
Penetration testing and code audits are separate services. This page covers the development practices that make those tests find less.
SSDF checklist
What do we set up for each SSDF practice group?
The four groups come from NIST SP 800-218. The middle column is what we put in place; the last is what you can show a reviewer afterwards.
| SSDF practice group | What Agnotic sets up | Evidence it leaves |
|---|---|---|
| Prepare the Organization (PO) | Security requirements per application, named roles, a secure coding standard and the pipeline tools to enforce it | Written requirements, the ASVS level record and tool configuration kept in the repository |
| Protect the Software (PS) | Branch protection, signed builds where the toolchain supports it, access reviews for repositories and build systems, a release archive | Repository settings, build provenance and the list of who can merge and deploy |
| Produce Well-Secured Software (PW) | Threat models for new features, code review rules, static analysis, dependency, secrets and infrastructure scans in CI | Threat model documents, pull request history and scan results attached to each build |
| Respond to Vulnerabilities (RV) | An intake for reported issues, triage and fix targets, root cause notes that feed back into requirements | A vulnerability log with dates, fixes and the release that shipped each one |
ASVS levels
Which OWASP ASVS level should each application target?
Levels are chosen per application, and sometimes per component, from the data it holds and the harm a breach would cause.
02
Level 2
Example: A SaaS product that holds customer business data or personal data behind logins
Approach: The usual target for business software, with design review and testing of authentication, access control and data protection.
03
Level 3
Example: Payments, health records or systems where a breach causes serious harm
Approach: The deepest verification, applied to the components that hold the riskiest data rather than always to the whole estate.
Threat modeling
How does threat modeling fit into a sprint?
We use OWASP's four questions, kept short enough to run for any feature that changes how data moves.
What are we working on?
A data flow diagram of the feature: users, services, data stores and the trust boundaries between them.
What can go wrong?
Each boundary walked with STRIDE prompts: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
What are we going to do about it?
Each threat becomes a ticket with a control, an owner and a test, or an accepted risk signed off by the product owner.
Did we do a good job?
A check at the end of the sprint: tests pass, tickets are closed and the model is updated for the next change.
Which security checks go into the pipeline?
Checks run where engineers already work, on every pull request, with clear rules for what blocks a merge.
Static analysis (SAST)
Rules tuned to your languages and frameworks, with findings shown in the pull request instead of a separate report nobody reads.
Dependency scanning (SCA)
Known vulnerable packages flagged with the fixed version, plus a software bill of materials for each release.
Secrets scanning
Pre-commit and CI checks for keys and tokens, with a rotation runbook for anything already in the history.
Infrastructure as code checks
Terraform, CloudFormation or Kubernetes manifests checked for public storage, open network rules and missing encryption.
Triage rules
Severity thresholds that block a merge, and a way to accept or suppress a finding with a written reason.
Build provenance
Builds run in CI from reviewed code, with each artifact traceable to the commit that produced it.
Evidence
What evidence do customer and federal security reviews ask for?
- A secure development policy mapped to the NIST SSDF practices you follow
- The ASVS level each application targets and how it is verified
- Threat models for the main data flows
- Scan results and the rules that block a release
- A vulnerability log showing how reported issues were fixed
- For software sold to US federal agencies, the inputs needed to complete CISA's Secure Software Development Attestation Form, which your company signs as the producer
OWASP SAMM
How do we build an application security roadmap?
OWASP SAMM gives the roadmap a measurable starting point and target.
1.
Assess
Score current practice against SAMM's five business functions: Governance, Design, Implementation, Verification and Operations.
Assess2.
Set targets
Pick a target maturity per practice for the next planning period, sized to your team and to what your customers ask for.
Plan3.
Build and measure
Add the practices to the delivery process, then reassess so progress is measured rather than assumed.
ImproveWho needs application security consulting?
SaaS companies facing enterprise questionnaires
Teams losing time on long security reviews that ask for a secure development process with evidence.
Startups preparing for a SOC 2 audit
Change management and secure development controls built into delivery before the auditor arrives.
Companies selling software to US federal agencies
Producers who need SSDF practices in place and documented for an attestation.
Product teams after a security incident
A root cause that points to process gaps, not just one bug.
Fintech and health products
Applications holding payment or health data that need a higher ASVS level on their riskiest parts.
Frameworks
Frameworks we map your practice to
NIST SP 800-218OWASP ASVS 5.0OWASP SAMMOWASP Top 10CISA attestation formSOC 2
Facts and sources
Facts behind a secure development lifecycle
The frameworks this page relies on, each from the body that publishes it.
NIST's Secure Software Development Framework (SP 800-218) organizes its practices into four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV).
Source: NIST CSRC: Secure Software Development FrameworkOWASP ASVS 5.0 defines three security verification levels, L1, L2 and L3, each increasing in depth, and suggests starting at the first level and moving up as the application's risk requires.
Source: OWASP ASVS 5.0: What is the ASVSOWASP SAMM defines five business functions and fifteen security practices that organizations use to assess and improve their software security posture.
Source: OWASP SAMM: the modelOWASP's threat modeling guidance organizes the work around four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job.
Source: OWASP: threat modelingCISA released the Secure Software Development Attestation Form on March 11, 2024, for producers of software used by the US federal government, based on practices from the NIST SSDF.
Source: CISA: Secure Software Development Attestation Form
Scope
What drives the scope of application security consulting?
We do not publish prices. These factors decide the size of the work.
Applications and repositories
How many products, services and repositories are in scope.
What is in place today
Existing tools, policies and reviews that can be kept and tuned.
Target ASVS levels
Higher levels on more components mean more design review and testing.
Evidence deadlines
A customer review, audit window or federal attestation with a fixed date.
Languages and platforms
Each stack needs its own analysis rules and tuning.
Team size
How many engineers need training on the new practices.
Frequently Asked Questions
It depends on how many applications and repositories are in scope and what is already in place. We start with a current-state map against the SSDF, then agree which gaps to close first.
Penetration testing is a separate service. Application security consulting changes how software is built, so later tests find fewer issues. We can plan both together.
No consulting engagement does that by itself. The practices and evidence we set up support the secure development and change controls your auditor reviews, but attestation and certification come from your auditor.
Yes. We add checks to GitHub Actions, GitLab CI, Azure DevOps or Jenkins pipelines you already run, and tune the rules so they block real problems instead of every warning.
We set up and document the SSDF practices the form asks about and gather the evidence behind each answer. The attestation itself is signed by your company, because it is a statement by the software producer.
For a product team it means a secure development program: requirements, design review, pipeline checks and vulnerability response, measured with OWASP SAMM. Company-wide policies stay with your security or compliance lead.
AI-generated code goes through the same static analysis, dependency and secrets checks and human review as any other change, and AI coding tools that touch sensitive code are covered in the threat model.