01
Security assessment
Example: Where are we weakest, and what should we fix first?
Approach: Architecture and code review with light testing. Output: a ranked list of risks and fixes.
Security Testing
Security testing for web, API and mobile applications
A customer's security review, a launch or an audit asks the same question: can someone break this? Agnotic Technologies picks the test that answers your question, runs it within the rules your cloud provider sets, and retests every fix.
OWASP mappedPenetration testsProvider rules followedRetest included
Trusted by global innovators
Application security testing
What is security testing, and which test do you need?
Security testing is checking an application for weaknesses an attacker could use, with the test type matched to the question you need answered: code scanning, dependency checks, dynamic scans, manual penetration tests, API and mobile tests, or a cloud configuration review. Agnotic Technologies scopes each engagement, maps it to OWASP guides and retests every fix.
We test applications: web apps, APIs, mobile apps and the cloud configuration they run on. We do not run social engineering, phishing or physical tests.
For healthcare products, the PHI threat model and our penetration testing approach for patient data are described on our healthcare security and privacy page.
Decision table
Which security test answers your question?
Start from the question, not the test name. Most engagements combine two or three rows.
| Question you need answered | Test type | Standard we map to | What you get |
|---|---|---|---|
| Does our code contain known insecure patterns? | Static analysis (SAST) in your pipeline | OWASP ASVS requirements | Findings per change, triaged so developers see real issues first |
| Are our open source libraries vulnerable? | Software composition analysis (SCA) | Published advisories for each package | A dependency list with the fixed version to move to |
| What can an outside attacker reach in the running app? | Dynamic scan (DAST) plus a manual penetration test | OWASP Web Security Testing Guide | Proven findings by severity with reproduction steps |
| Can one user or tenant see another's data through our APIs? | Authenticated API testing with accounts for every role | OWASP API Security Top 10 | Object and function level authorization findings |
| Can our mobile app leak stored data or be tampered with? | iOS and Android app testing on release builds | OWASP MASVS and MASTG | Findings grouped by MASVS control area |
| Is our cloud account set up safely for this app? | Cloud configuration review | The provider's security guidance and CIS Benchmarks | Misconfigurations with the setting that fixes each one |
A scan alone finds known patterns. Authorization flaws, the most common serious API findings, usually need a person testing with real accounts.
Assessment, audit or test
What is the difference between a security assessment, a security audit and a penetration test?
Buyers use these words loosely. This is how we scope each one for an application.
02
Security audit
Example: Does the application meet the standard we promised, such as an OWASP ASVS level or a customer's security schedule?
Approach: Requirement by requirement review with evidence. Output: pass, fail or not applicable for each requirement.
03
Penetration test
Example: Can someone actually get in, and how far can they go?
Approach: Hands-on testing within agreed rules of engagement. Output: proven findings with reproduction steps.
04
Vulnerability scan
Example: What known issues do automated tools find today?
Approach: Automated scanning. Output: a raw list that still needs a person to triage it.
Code review or pentest
Source code review or penetration test: which finds what?
A secure source code review reads the code to find flaws such as hard-coded secrets, cryptography misuse and missing authorization checks. A penetration test attacks the running application to prove what an attacker can exploit. Agnotic Technologies follows the OWASP Code Review Guide for the first and the OWASP Web Security Testing Guide for the second.
| Flaw class | Secure code review | Penetration test | Best approach |
|---|---|---|---|
| Injection (SQL, command, template) | Finds every query or command built from user input, including paths no tester reaches | Proves which inputs can be exploited from outside, and how far | Both: the review finds the full set, the test shows the impact |
| Broken authorization | Shows where a check is missing, but not always which roles can reach that path | Proves one user or tenant can reach another's data, using accounts for each role | Penetration test first, then code review to find every route with the same gap |
| Business logic | Hard to see in code without knowing the intended flow | Abuses the real flow: skipped steps, repeated discounts, negative quantities | Penetration test, with your product owner describing the intended rules |
| Cryptography misuse | Weak algorithms, home-made schemes and fixed keys are visible in the code | Rarely visible from outside unless the output itself is weak | Code review |
| Hard-coded secrets | Keys and passwords in code, configuration files and repository history | Found only if a secret leaks into a response or a public file | Code review plus a secrets scan of the full history |
| Server and cloud configuration | Visible only where infrastructure as code is in scope | Finds exposed ports, verbose errors, weak TLS and open storage on the live system | Penetration test, plus a review of the cloud account settings |
In a white-box test, testers get the source code as well as accounts. They use the code to aim at risky paths and the running system to prove each finding, so one report covers both views. It suits products with large APIs or many roles, where testing from outside alone leaves paths unvisited.
OWASP mapping
Which OWASP guide applies to each target?
We write the test plan against these guides, so you can see what was covered and what was not.
Web applications
- OWASP WSTG test areas: identity, authentication, session management, input validation, business logic
- OWASP ASVS requirements at the level you agreed with your customers
APIs
- API1 Broken Object Level Authorization
- API2 Broken Authentication
- API4 Unrestricted Resource Consumption
- API5 Broken Function Level Authorization
Mobile apps
- MASVS-STORAGE and MASVS-CRYPTO for data on the device
- MASVS-AUTH and MASVS-NETWORK for sign-in and traffic
- MASVS-RESILIENCE where tampering matters
Cloud configuration
- Identity and access policies
- Public storage and network exposure
- Logging and encryption settings
Penetration testing
How do we scope and run a penetration test?
The steps behind every application penetration test we run.
Scope the targets
We list the URLs, API base paths, app builds and cloud accounts in scope, and write down what is out of scope.
Agree the rules of engagement
Test windows, environment (staging where it matches production), source addresses, stop conditions and who to call if something breaks.
Set up accounts for every role
Two accounts per role and per tenant, so we can test whether one user can reach another's data.
Test
Automated discovery first, then manual testing against the OWASP guide for each target. Anything critical is reported the same day.
Report
Findings by severity with reproduction steps, impact and fix guidance, plus a short summary you can share with customers.
Fix and retest
We retest each fixed finding and issue a retest letter listing what was closed and what remains open.
Do you test the network around your application?
Yes. Our network penetration testing covers the network your application runs in: internet-facing hosts and open ports, TLS configuration, exposed admin and database services, cloud security groups and segmentation between tiers. Agnotic Technologies does not test corporate office networks, Wi-Fi or physical entry, and follows NIST SP 800-115 for test techniques.
In scope: hosts and open ports
We find every host and port that belongs to the application, then check that only the ones it needs answer from the internet.
In scope: TLS configuration
Protocol versions, cipher suites, certificate chains and redirects to HTTPS on every public endpoint.
In scope: admin and database services
Admin consoles, database ports, caches and message brokers that should be private, and default or weak credentials on them.
In scope: security groups and segmentation
Firewall and security group rules, public storage, and whether the web tier reaches only what it should in the data tier.
Network vulnerability assessment
Repeat scans of the same hosts on a schedule, so a newly opened port or an expiring certificate is caught between penetration tests.
Out of scope: corporate networks
Office networks, employee devices, Wi-Fi and VPN estates are infrastructure security work, which we do not offer.
Cloud provider rules
What do AWS and Azure allow you to test?
Cloud providers set their own rules for testing on their platforms. We check the current rules before every test window.
- On AWS, listed services such as Amazon EC2, Amazon RDS, AWS Lambda and Amazon API Gateway can be tested without prior approval; other services need AWS Support involved first
- AWS prohibits DoS, DDoS, port flooding and request flooding in normal penetration tests; those fall under its separate DDoS Simulation Testing policy
- Microsoft publishes its own security testing rules of engagement for its online services, and we follow the version current on the test date
- For Google Cloud, we check Google's current terms for testing your own projects before the window opens
- We test only accounts and resources you own or are authorized to have tested, with that authorization in writing
How do we test DDoS resilience without breaking provider rules?
We review the controls that absorb a flood, not the flood itself. That means rate limits per user and per API key, web application firewall rules, autoscaling limits, CDN caching and the alarms that tell your team an attack has started.
We confirm each control is configured and fires, using request volumes far below flood level and agreed in the rules of engagement. API4, Unrestricted Resource Consumption, is part of every API test we run.
A volumetric DDoS simulation on AWS has to be run by an AWS DDoS Test Partner against a resource protected by AWS Shield Advanced. If you need one, we prepare the scope and the controls first and work alongside the partner you choose.
Vulnerability assessment
How often should an application be scanned for vulnerabilities?
An application should be scanned for vulnerabilities on a fixed schedule and after events: a major release, a new integration, an infrastructure change or a newly published flaw in a component it uses. Agnotic Technologies sets the scan schedule and fix deadlines from the rules that apply to you, such as NIST SP 800-53 control RA-5 or CISA BOD 22-01.
NIST SP 800-53 Rev. 5, control RA-5
- Scan the system and hosted applications at a frequency the organization defines
- Scan again when new vulnerabilities that may affect the system are reported
- Applies to federal systems and to programs that adopt the NIST control catalog
CISA BOD 22-01
- Federal agencies must fix vulnerabilities listed in CISA's Known Exploited Vulnerabilities catalog by set deadlines
- Default deadlines in the directive: two weeks, or six months for CVE IDs assigned before 2021
- Applies to federal information systems, including those hosted by third parties for an agency
Release and change events
- A major release or a new public API
- A new integration with a payment, identity or partner system
- A change to infrastructure or cloud configuration
- A rescan after fixes, to confirm each finding is closed
Between scheduled scans
- Dependency alerts on every repository for newly published advisories
- New advisories matched against the components each product uses
- Fix order set by exploitation and exposure, as our maintenance page describes
Penetration tests on a slower rhythm
- A vulnerability assessment is broad and repeats on the schedule above
- A penetration test is deep and manual, so it runs before major releases, customer security reviews or audits
- Findings from both go into one tracked list
What the assessment report adds to scanner output
- False positives removed after a person checks each finding
- Remaining findings ranked by exposure and reachability, not by tool severity alone
- An owner and a fix target for every finding, confirmed by rescan
When teams ask
When do teams ask us for security testing?
Most requests come from a deadline that someone outside the team has set.
An enterprise customer's security review
The buyer asks for a recent penetration test and evidence that findings were fixed.
Before a launch or major release
New APIs, a new mobile app or a new payment flow tested before real users arrive.
Audit preparation
Test results and retest letters that feed SOC 2 or customer audit evidence.
Security testing for startups
A first test scoped to the parts of the product that hold customer data, at a size an early team can fix.
After an incident or a near miss
A focused test of the area involved, plus the paths an attacker could take next.
Standards
Standards we test against
Public methods, so your team and your customers can check what a test covered.
OWASP WSTGOWASP ASVSOWASP API Top 10OWASP MASVSNIST SP 800-115AWS policyOWASP Code Review GuideNIST SP 800-53 RA-5
Facts and sources
Facts behind security testing
Methods and provider rules that shape a security test, each linked to its primary source.
NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (September 2008), covers penetration testing, vulnerability scanning and security assessment methods.
Source: NIST SP 800-115 (NIST CSRC)The OWASP Application Security Verification Standard (ASVS), at version 5.0.0, provides a basis for testing web application technical security controls and a list of requirements for secure development.
Source: OWASP ASVS project page (OWASP Foundation)The OWASP API Security Top 10 2023 ranks Broken Object Level Authorization as API1, the risk that one user can read or change another user's records by changing an ID in a request.
Source: OWASP API Security Top 10 2023 (OWASP Foundation)AWS customers may run security assessments or penetration tests on listed services, such as Amazon EC2, Amazon RDS, AWS Lambda and Amazon API Gateway, without prior approval, while DoS, DDoS and request flooding are prohibited outside the DDoS Simulation Testing policy.
Source: AWS Customer Support Policy for Penetration Testing (AWS)On AWS, a DDoS simulation test must be run by a pre-approved AWS DDoS Test Partner against a resource protected by AWS Shield Advanced, within published limits on bit, packet and request volume.
Source: AWS DDoS Simulation Testing Policy (AWS)
Scope and cost
What drives the cost of security testing?
Each test is priced from its scope, not a rate card. These are the factors that set that scope.
Targets
How many web apps, API services, mobile apps and cloud accounts are in scope.
Roles and tenants
How many user roles and tenant types need their own accounts and authorization tests.
Depth
Unauthenticated testing only, or authenticated testing of every role and business flow.
Environments
Whether a staging environment matches production, or testing has to happen in production windows.
Retest rounds
How many retest rounds you need before a customer review or audit date.
Reporting
Whether you need a customer-facing summary or an audit mapping as well as the technical report.
Frequently Asked Questions
Tests are priced per scope. Cost follows the number of targets, roles and tenants, whether testing is authenticated, the environments available and the retest rounds you need. You get a written scope and price after the scoping call.
It depends on the targets and depth in scope, so we agree the test window in the rules of engagement before testing starts. Retests are scheduled once your team has fixed the findings.
Staging, when it runs the same code and configuration as production. Some checks, such as cloud configuration and public exposure, have to look at production, and those are agreed in the rules of engagement.
Yes. Every engagement includes a retest of the fixed findings and a retest letter that lists what was closed and what is still open, which is what most customer security reviews ask for.
Yes. One scope can cover all three, with a test plan per target mapped to the matching OWASP guide and one report that shows how a finding in one target affects the others.
Static analysis and dependency checks can, and we set them up to fail a build only on findings your team agrees are real. Manual penetration testing still happens on a schedule or before major releases.
We review and test the controls that stop a flood, such as rate limits, firewall rules and autoscaling, at low volume. A volumetric DDoS simulation on AWS must be run by an AWS DDoS Test Partner, and we work alongside the one you choose.
Tools, including AI-assisted ones, help with discovery and triage. Every finding in our report is confirmed by an engineer who reproduced it by hand, so the report has no unverified tool output.