Find the vulnerabilities in your system before attackers do.

The average time between a breach and its discovery is 197 days. You cannot afford to be the last to know.

Security vulnerabilities do not announce themselves. SQL injection in a ten-year-old API endpoint, an S3 bucket with public read access that no one noticed, a JWT with a predictable secret, an admin panel with no rate limiting — these exist in production systems built by competent engineering teams who were focused on shipping features, not modelling attacks. PROPELOO security assessments are not compliance exercises. They are structured adversarial examinations designed to find what an attacker would find, documented with enough specificity to fix, and delivered with the goal of making the system genuinely harder to compromise — not to generate a report that sits in a SharePoint folder until the next audit cycle.

The full security assessment stack.

Application security requires different methodologies for different attack surfaces. Each requires a distinct toolset and mindset.

System Layers

• Reconnaissance & Mapping: Attack surface enumeration, technology fingerprinting, endpoint discovery, exposed credential scanning
• Vulnerability Assessment: Automated scanning, manual verification, CVSS scoring, false positive triage
• Penetration Testing: Authenticated and unauthenticated exploitation, privilege escalation, lateral movement, data exfiltration simulation
• Secure Architecture Review: Threat modelling, trust boundary analysis, security design review, zero-trust assessment
• Remediation & Verification: Fix guidance, developer training, re-testing after remediation, security regression testing

Core Technical Capabilities

• Web Application Penetration Testing

  OWASP Top 10 coverage, authentication bypass, authorisation flaws, injection attacks (SQL, NoSQL, SSTI), XSS, CSRF, IDOR, business logic vulnerabilities and session management issues.

• API Security Testing

  REST and GraphQL API security — authentication/authorisation bypass, BOLA/IDOR, mass assignment, rate limiting bypass, GraphQL introspection abuse, injection via API parameters and JWT vulnerabilities.

• Cloud Security Assessment

  AWS/GCP/Azure IAM review for least-privilege violations, publicly exposed resources, secrets in environment variables, misconfigured security groups, S3 bucket policies and CloudTrail coverage gaps.

• SAST & Code Review

  Static analysis with Semgrep, CodeQL and custom rule sets. Manual code review for authentication logic, authorisation enforcement, cryptographic implementation and input validation. Security-focused pull request review.

• Threat Modelling

  STRIDE threat modelling for application architecture — data flow diagrams, trust boundary identification, threat enumeration and risk-ranked mitigation recommendations. Delivered before development begins.

• Smart Contract Security

  Solidity and Rust/Anchor smart contract security review — reentrancy, access control, arithmetic errors, oracle manipulation, flash loan attack surface and economic model review.

How we think about application security.

Security testing without adversarial thinking is not security testing — it is a checklist. A real attacker does not stop at the first obstacle. They chain low-severity issues into critical exploits.

• Think like an attacker, report like an engineer

  A penetration test that finds "SQL injection in the login form" is not useful. A penetration test that demonstrates: "SQL injection in /api/v1/login allows unauthenticated extraction of the users table including password hashes, which when cracked give admin access to the application and SSH credentials reused from the database" — that is useful. We do not stop at the vulnerability. We trace the full exploitation path.

  Axiom:

• Business logic bugs are the hardest to scan for

  Automated scanners find injection, XSS and known CVEs. They do not find: the API endpoint that allows a user to read another user's private data by changing a numeric ID (IDOR), the admin function that enforces the role check in the UI but not the API, or the discount code that can be applied multiple times by replaying the request. These require a human tester who understands the application's intended behaviour and actively tries to circumvent it.

  Axiom:

• Severity is about business impact, not CVSS score

  A medium-CVSS SQL injection in a public endpoint that exposes PII for millions of users is more critical to your business than a critical-CVSS vulnerability in an internal tool used by two people. We score and prioritise findings by business impact — real-world exploitability, data sensitivity, regulatory implications and reputational risk — not just the theoretical CVSS calculation.

  Axiom:

• Security debt compounds

  A security vulnerability found before deployment costs hours to fix. The same vulnerability found in a penetration test after launch costs days. The same vulnerability found by an attacker costs months of incident response, regulatory investigation and user trust rebuilding. The return on investment for early security engagement is not primarily the vulnerabilities found — it is the vulnerabilities prevented from ever reaching production.

  Axiom:

The security decisions that shape your risk profile.

These choices determine your attack surface, your detection capability and your response time.

• Penetration test vs vulnerability assessment?

  Impact: For compliance: vulnerability assessment. For actual security improvement: penetration test. For mature security programmes: red team. Never mistake a vulnerability scan for a penetration test — they are fundamentally different exercises with different outputs.

  • Vulnerability assessment — automated scanning, identifies known CVEs, no exploitation, lower cost
  • Penetration test — manual exploitation, chains vulnerabilities, demonstrates real impact, higher cost
  • Red team exercise — full adversarial simulation, tests detection and response, not just prevention
  • Bug bounty programme — continuous coverage, pay-per-finding, requires programme management

• Black box vs grey box vs white box?

  Impact: White box testing finds significantly more vulnerabilities than black box for the same time investment. We recommend grey or white box testing for applications where finding the most issues matters more than simulating a naive external attacker.

  • Black box — no prior knowledge, simulates external attacker, misses internal logic issues
  • Grey box — user credentials, basic documentation, most realistic for insider threat model
  • White box — full source code and architecture access, highest coverage, finds the most issues
  • Hybrid — black box first, then white box for targeted deep dive

• SAST vs DAST vs manual review?

  Impact: SAST and DAST are complementary, not alternatives. SAST finds issues in code that DAST cannot access. DAST finds runtime issues (authentication bypass, session management) that SAST cannot detect. Manual review finds business logic vulnerabilities that neither tool will catch.

  • SAST only — finds code patterns, high false positive rate, no runtime context
  • DAST only — finds runtime issues, misses source code logic, no coverage of undeployed code
  • Manual code review — highest quality, covers business logic, expensive and slow
  • SAST + DAST + manual — maximum coverage, appropriate for security-critical applications

• When to do threat modelling?

  Impact: Threat modelling before development is worth 10x the same exercise after launch. Design-level security decisions (authentication model, trust boundaries, data classification) cannot be changed cheaply after implementation.

  • Before development begins — cheapest to implement findings, highest ROI
  • At architecture review — catches design-level issues before code is written
  • Before penetration test — gives testers context, improves test quality
  • After launch — retrospective value only, expensive to implement findings

• How often should you test?

  Impact: A product that ships weekly but tests security annually is testing a system that no longer resembles what was tested. SAST in the CI pipeline catches new vulnerabilities on every commit. Annual manual penetration tests catch what SAST misses.

  • Once a year — minimum for compliance, insufficient for active development
  • Before major releases — tests what changes, misses baseline drift
  • Quarterly — good for active products, catches accumulated technical security debt
  • Continuous (SAST in CI + periodic manual) — ideal, catches issues before production

• What to do with findings?

  Impact: A finding that is not fixed and not formally accepted as risk creates liability. Every finding needs a decision: fix, mitigate, accept or transfer. "We'll get to it" is not a risk management strategy.

  • Fix all critical immediately, schedule high/medium — minimum acceptable
  • Risk-rank by business impact, fix top 20% that address 80% of risk — pragmatic
  • Fix everything before next release — appropriate for regulated industries
  • Accept risk for findings below a threshold, document and revisit — valid with governance

What PROPELOO assesses.

• Web Application Pentest

  Full OWASP Top 10 coverage, authentication/authorisation testing, business logic review, session management and privilege escalation — with PoC for every finding.

• API Security Assessment

  REST and GraphQL API testing — BOLA/IDOR, authentication bypass, rate limiting, mass assignment, injection via API parameters and JWT vulnerability assessment.

• Cloud Security Review

  AWS/GCP/Azure configuration review — IAM least-privilege analysis, publicly exposed resources, secrets management gaps, network segmentation and logging coverage.

• Smart Contract Audit

  Solidity and Rust smart contract security review — reentrancy, access control, arithmetic errors, oracle manipulation and economic attack modelling.

• Threat Modelling

  STRIDE threat modelling for new systems before development — data flow diagrams, trust boundary analysis, threat enumeration and risk-ranked security requirements.

• Secure Code Review

  Security-focused code review of critical application components — authentication, authorisation, cryptography, input handling and third-party integration security.

The security assessment toolchain.

Different attack surfaces require different tools. The combination determines coverage depth.

• Web & API Testing

  Stack: Burp Suite Pro, OWASP ZAP, Postman, ffuf, nuclei, sqlmap

• SAST

  Stack: Semgrep, CodeQL, SonarQube, Bandit (Python), ESLint security rules

• Cloud Security

  Stack: Prowler, ScoutSuite, Checkov, tfsec, AWS Config, CloudTrail

• Network & Infrastructure

  Stack: Nmap, Nessus, Nikto, Shodan, Masscan

• Smart Contract

  Stack: Slither, Mythril, Echidna, Foundry, Semgrep (Solidity rules)

• Reporting & Management

  Stack: Dradis, PlexTrac, Custom CVSS scoring, Jira integration

The vulnerability classes we test for.

Each requires a different testing methodology. Automated tools catch some. Manual testing catches the rest.

• Injection Attacks

  SQL injection, NoSQL injection, LDAP injection, OS command injection, SSTI and XML injection — all require both automated scanning and manual testing with application-specific payloads. Parameterised queries prevent SQL injection in the code; automated scanners confirm that the prevention is actually implemented correctly across every endpoint.

• Broken Access Control (OWASP #1)

  IDOR (changing numeric IDs in API requests to access other users' data), missing function-level access control (admin endpoints accessible to non-admin users), path traversal, and JWT manipulation to escalate privileges. Broken access control is the most common critical finding in web application penetration tests and the least likely to be caught by automated scanning.

• Authentication & Session Management

  Weak passwords accepted, no account lockout after failed attempts, JWT with weak secrets or algorithm confusion attacks (RS256 to HS256), session tokens predictable or not invalidated on logout, password reset tokens that do not expire, and OAuth misconfiguration allowing token theft.

• Security Misconfiguration

  Default credentials, verbose error messages exposing stack traces, directory listing enabled, unnecessary services running, CORS misconfiguration allowing credential sharing with arbitrary origins, missing security headers (HSTS, CSP, X-Frame-Options) and debug mode enabled in production.

• Cryptographic Failures

  PII transmitted over HTTP, passwords stored without hashing or with weak algorithms (MD5, SHA1 without salt), encryption keys hardcoded in source code, use of ECB mode for block cipher encryption, and custom cryptography implementation instead of vetted libraries.

• Supply Chain & Dependency Security

  Outdated dependencies with known CVEs, malicious package installation via typosquatting, build pipeline compromise, secrets in CI/CD environment variables exposed in logs, and container images built from unverified base images with known vulnerabilities.

The PROPELOO security assessment process.

1. 01. Scoping & Rules of Engagement

   Define scope (in-scope domains, APIs, IPs), testing methodology, timing, communication protocol and escalation path for critical findings discovered during testing.

2. 02. Reconnaissance

   Passive and active reconnaissance — technology fingerprinting, endpoint enumeration, exposed credential scanning, third-party exposure and attack surface mapping.

3. 03. Automated Assessment

   Authenticated and unauthenticated automated scanning. SAST on provided source code. Cloud configuration review. False positive triage before manual testing begins.

4. 04. Manual Penetration Testing

   Manual exploitation of automated findings. Business logic testing. Authentication and authorisation bypass attempts. Privilege escalation and lateral movement simulation.

5. 05. Exploitation & Impact Demonstration

   For critical and high findings: proof-of-concept exploitation demonstrating real business impact — data extracted, accounts compromised, systems accessed.

6. 06. Report Delivery

   Executive summary for non-technical stakeholders + technical report with every finding: description, evidence, CVSS score, business impact, remediation steps and risk rating.

7. 07. Remediation Support & Re-test

   Developer Q&A on findings, remediation guidance and re-test of all critical and high findings after fixes are applied. Final security attestation.

Cybersecurity & Application Security Engagements

Adversarial penetration testing, cloud hardening and DevSecOps pipelines protecting sensitive data.

• Full-Scope Penetration Testing for Banking Application

  Challenge: Digital bank required independent red-team penetration test of core web banking, mobile APIs, and administrative backend prior to regulatory license review.

  Architecture: Black-box and gray-box penetration testing covering OAuth 2.0 / JWT flows, BOLA/IDOR vulnerabilities, business logic bypasses, SQL/NoSQL injection, and API rate-limiting stress testing.

  Outcome: Uncovered 3 High-severity vulnerabilities including a BOLA vector in transaction receipt generation. Provided verified remediation code snippets and re-tested within 10 days. Enabled full regulatory license approval.

• Cloud Security Posture Assessment & Threat Modelling

  Challenge: HealthTech platform needed comprehensive security assessment of HIPAA compliance, AWS infrastructure, and container pipelines.

  Architecture: STRIDE threat modelling of all patient data paths, automated IaC security scanning with Checkov, AWS configuration auditing with Prowler, and container image vulnerability scanning in CI/CD.

  Outcome: Resolved 42 infrastructure misconfigurations, closed public S3 exposure risks, and delivered comprehensive HIPAA-aligned security architecture documentation.

• DevSecOps Pipeline Integration & Automated SAST/DAST

  Challenge: Engineering team of 40 developers was shipping code with recurring dependency vulnerabilities and unreviewed security debt.

  Architecture: Integrated Semgrep and Snyk into GitHub Actions pull request gates, automated OWASP ZAP dynamic scanning in staging, and implemented security dashboard tracking mean-time-to-remediate (MTTR).

  Outcome: Reduced production security vulnerabilities by 84%. Average vulnerability remediation time dropped from 32 days to 3.5 days.

Frequently Asked Questions