Ravindu Fernando/Scorecard

AppSec Maturity Scorecard

Twelve plain-language questions across the six areas I assess in every engagement. You get an instant score for each area, and a short report with the next three actions for each.

01Edge & WAAP2 questions
02API security2 questions
03Vulnerabilities & exposure2 questions
04Monitoring & visibility2 questions
05Mobile apps2 questions
06Governance & maturity2 questions

Takes about 3 minutes

1 / 12 · Edge & WAAP

01 · Edge & WAAPOur internet-facing web applications and APIs sit behind a WAF or WAAP that actively blocks attacks.

Count only protection in blocking mode, not tools running in monitoring or detection mode.

0None, or only on a handful of applications1On most applications, but largely in monitoring or detection mode2On all public applications in blocking mode, tuned occasionally3All public applications blocking, tuned continuously, coverage checked against inventory

01 · Edge & WAAPOur edge also stops DDoS and malicious bots, and our origin servers cannot be reached directly.

Origin protection means attackers cannot bypass the edge by connecting straight to your servers.

0No dedicated DDoS or bot protection; origins are publicly reachable1Basic DDoS protection from our ISP or host; bots largely unmanaged2Always-on DDoS and bot mitigation; origins accept only edge traffic3Mitigation exercised regularly, bot controls tuned, origin lockdown verified

02 · API securityWe have a current inventory of all our APIs, including internal, partner-facing and older versions.

Include undocumented and deprecated endpoints, not only those listed in a developer portal.

0No central inventory; APIs are known only to individual teams1A manually maintained list that is partial or out of date2Inventory built from gateways and specifications, refreshed periodically3Continuous discovery from live traffic, reconciled with specifications and named owners

02 · API securityEvery API checks who the caller is, what they may access, and that requests match the expected format.

In plain terms: could one customer reach another customer's data by changing an ID in a request?

0We rely mainly on the network or the front end for protection1Authentication is consistent, but authorisation checks vary by team2Standard authentication and authorisation patterns, with schema validation at the gateway3Enforced centrally and tested against OWASP API Security Top 10 each release

03 · Vulnerabilities & exposureOur applications are tested for security flaws during development and before major releases.

This covers code scanning, dynamic testing of running applications and independent penetration tests.

0Rarely, usually only when an audit or regulator requires it1Annual penetration tests on key applications; little testing during development2Automated code and dynamic scanning in pipelines, plus periodic penetration tests3Risk-based testing in every pipeline, findings validated and fixes retested

03 · Vulnerabilities & exposureWe prioritise and fix vulnerabilities based on real business risk, within agreed timeframes.

Consider whether you know which findings are actually exploitable, not just which scored highest.

0No agreed timeframes; findings are fixed when teams find time1Deadlines set by severity score alone, and often missed2Prioritised by exploitability and asset value, with tracked fix deadlines3Continuous exposure management, validated risk, measured fix times and trend reporting

04 · Monitoring & visibilitySecurity events from our applications, APIs and edge controls flow into a central SIEM or log platform.

Think of failed logins, access-denied events, WAF blocks and admin actions, not just infrastructure logs.

0Logs stay on individual servers or are not kept1Some sources centralised, mostly infrastructure rather than application events2Key application, API and edge events centralised with defined retention3Comprehensive application telemetry, with coverage reviewed against the asset inventory

04 · Monitoring & visibilityApplication security alerts have a named owner and an agreed response procedure.

If an API or the WAF flagged an attack at 2am, who would see it and what would happen next?

0No one is specifically responsible for application security alerts1Alerts go to a shared inbox or team, handled on a best-effort basis2A SOC or named team triages alerts using documented playbooks3Owned, playbook-driven response with tuned detections and measured response times

05 · Mobile appsOur customer-facing mobile apps are protected against tampering, reverse engineering and use on compromised devices.

This means in-app protection such as obfuscation, anti-tamper, root or jailbreak detection and RASP.

If your organisation does not publish mobile apps, choose the first option on both questions and disregard this axis when reading your results.

0No in-app protection, or we do not publish mobile apps1Basic obfuscation or root detection on some apps only2App shielding with anti-tamper and RASP on all customer apps3Layered shielding on all apps, bypass-tested and updated each release

05 · Mobile appsOur mobile apps are security-tested against OWASP MASVS, and their runtime threat signals reach our security team.

Runtime telemetry tells you when apps in the field detect hooking, tampering or emulators.

0No mobile-specific testing or telemetry, or we have no mobile apps1Occasional mobile penetration tests; no runtime telemetry2Regular MASVS-based testing; some runtime signals collected but rarely reviewed3MASVS testing each major release; telemetry monitored by security and fraud teams

06 · Governance & maturityApplication security has a named owner, an approved policy and a risk appetite agreed with leadership.

Ownership means one accountable person or team, not responsibility spread across IT, security and development.

0No clear owner; application security is handled case by case1Owner named, but policy and risk appetite are informal or outdated2Owner, approved policy and risk appetite, reviewed at least annually3Board-visible ownership, with current policy and risk appetite guiding release decisions

06 · Governance & maturityWe measure application security maturity and fund a multi-year improvement roadmap.

For example, a periodic assessment against OWASP SAMM v2 or NIST CSF 2.0 that informs budget.

0Maturity has never been measured; spending is reactive1One-off assessment completed, but no roadmap or dedicated budget2Periodic framework-based assessment, with a roadmap and annual budget3Maturity tracked over time, with roadmap and budget tied to measured progress

Your result

Full report

The next three actions for each area.

Name *

Work email *

Organisation *

Company website

Your email is used only to send your report and occasional relevant insights, is never shared with anyone, and you can unsubscribe at any time. Privacy notice

Full report

Discuss my results

FAQ

About the scorecard.

What does the scorecard measure?

How mature your application security is across six areas: edge and WAAP, API security, vulnerabilities and exposure, monitoring and visibility, mobile apps, and governance. Each area has two plain-language questions scored 0 to 3, giving an overall percentage and a score per area.

Is it the same as a formal assessment?

No. It is a quick, self-reported indicator. A formal assessment uses evidence and interviews across teams and produces a defensible baseline and roadmap. The scorecard shows where that deeper look is most likely to pay off.

What happens to my answers and email?

Answers are scored in your browser. If you request the full report, your name, email, organisation and scores are stored securely so Ravindu can follow up once if you want him to. They are never shared or sold, and you can ask for deletion at any time.