AiVRIC Web Security Foundations • Practitioner

Web Security

Web security is the governance and operation of controls that protect public-facing applications, APIs, endpoints, identity flows, cloud edge services, and exposed infrastructure. In CloudSignals+RiskOps, web security is approached through asset context, exposure findings, control requirements, evidence, risk treatment, and remediation workflows — not limited to application vulnerability testing.

Topic course: ~90 min • Certification path: 5–7 hrs 6 modules + capstone Foundational to Intermediate Certification eligible

Who this course is for

Application security analysts
Cloud security analysts
Web platform owners
DevSecOps engineers
RiskOps teams
Compliance managers

Prerequisites

Basic understanding of web applications, APIs, and internet exposure
Familiarity with security findings and remediation workflows
Access to Surface, Findings, RiskOps, and Governance & Assurance views

What you will be able to do

Explain web security as an asset, control, and risk governance discipline — not just application vulnerability testing.
Identify public exposure and web-facing assets using Surface and Cloud Resources views.
Prioritize web findings using risk context including business function, data sensitivity, and owner accountability.
Map web security gaps to UCB controls and evidence expectations.
Route web security remediation through RiskOps projects with owner, SLA, and verification criteria.
Use Vision to draft web risk narratives — with required human review and attestation.

Platform areas used in this course: Surface, Assets, Cloud Resources, Findings, Governance & Assurance, Control Library, Evidence Fabric, RiskOps, Projects, Risk Treatments, Reports, Vision. Navigate to Surface > Assets to begin.

AI advisory statement: Vision can draft web risk narratives and executive summaries — but all output must be reviewed for accuracy, corrected where needed, have source references added, and carry the reviewer's attestation and AI disclaimer before distribution or use as evidence.

Web Security Governance

15 min • Control Library • Explain web controls, governance scope, and why they exist

Web security governance is broader than application vulnerability testing

Web security is not limited to finding SQL injection or XSS vulnerabilities in application code. It includes governance over: public endpoints (authentication, API access controls, exposed management interfaces), authorization and session handling (token validity, session timeout, privilege escalation paths), TLS and transport security (protocol versions, cipher suites, certificate validity), DNS governance (subdomain takeover exposure, DNSSEC configuration), WAF and edge controls (web application firewall configuration, DDoS protection, rate limiting), API exposure (authentication, CORS, authorization checks, rate limiting), secrets handling (API keys, credentials, certificates not stored in code or public storage), logging and monitoring (access logs, anomaly detection, audit trails for sensitive operations), and secure change governance (change review for web-facing components).

CloudSignals+RiskOps helps learners connect these web security risks to assets, findings, controls, evidence, and remediation — creating a governance chain from exposure detection through to verified closure.

In the platform — Identify web security controls in the Control Library

Navigate to Governance & Assurance > Control Library. Search or filter for web-security-relevant domains: Infrastructure Security, Identity & Access Management, Data Protection, and Network Security.

Select a web-relevant control (e.g., "Enforce HTTPS on all public endpoints" or "Restrict public storage access"). Review the control's objective, guidance, and applicable dimensions — this is why this control exists, not just what it requires.

Review the Assessment Objectives for the control. Note what evidence types are expected — this will guide Module 4's evidence work. Web security controls often require both automated scanner evidence AND human-reviewed configuration confirmation.

Identify the three UCB controls most relevant to your organization's web-facing infrastructure. These will anchor your labs throughout this course.

Map web security governance scope: List which of the nine web governance areas are in scope for your organization (endpoints, auth, TLS, DNS, WAF, API, secrets, logging, change governance).

Identify your three anchor controls: From the Control Library, select the three UCB controls most critical to your web-facing environment. These drive your Module 2–5 work.

Note evidence expectations: For each anchor control, record what evidence types are expected so you can collect them in Module 4.

Knowledge Check

Name five types of web-facing assets that should appear in a complete web security asset inventory.

Virtual machines, databases, Kubernetes clusters, container registries, and CI/CD pipelines.

Public cloud endpoints, load balancers, web applications, APIs and API gateways, and storage buckets with public access — all of which are directly reachable from the internet and represent the organization's web attack surface.

Network security groups, firewall rule sets, DDoS protection policies, VPN configurations, and private DNS zones.

Code repositories, artifact registries, secrets vaults, IaC templates, and configuration management databases.

Move on when you've identified your three anchor UCB controls and noted their evidence expectations.

Web-Facing Asset Discovery

20 min • Assets, Cloud Resources • Build a complete web exposure inventory

Ten categories of web-facing assets

Web-facing assets are those that are directly reachable from the public internet or indirectly exposed through integrations with internet-facing systems. A complete web exposure inventory covers ten asset categories:

Public cloud endpoints

Direct internet-accessible services with open ports or public IP addresses

Load balancers

Internet-facing ingress points routing to backend services

Web applications

HTTP/HTTPS services serving user-facing interfaces

APIs

REST, GraphQL, or SOAP endpoints with external access

Storage with public access

Buckets or blob containers accessible without authentication

CDN distributions

Edge caches that may expose origin URLs or sensitive content

DNS records

Subdomains and records that may expose internal services or be taken over

Identity endpoints

Internet-facing VMs

Compute instances with public IPs and open management or service ports

SaaS integrations

Third-party platforms with OAuth tokens or API access to your systems

For each web-facing asset, governance requires determining: ownership, business function, data sensitivity, and exposure scope (intentional vs. accidental public access). Unintentional public exposure is your highest-priority finding — an asset that should not be public but is creates direct exploitation opportunity with no exploitation barrier.

In the platform — Lab 1: Web Exposure Review

Navigate to Surface > Assets. Filter for assets tagged "public" or with the public exposure attribute. Review the list — these are your internet-facing governance targets.

Navigate to Surface > Cloud Resources. Filter by the "public access" or "internet-facing" attribute. For each identified asset: confirm the exposure is intentional, note the business function, owner, and data sensitivity.

Identify any assets that should not be publicly accessible. These are your unintentional exposures — the highest-priority findings in your web security inventory. Flag each for immediate triage.

For each web-facing asset, confirm a named owner is assigned. Unowned web-facing assets cannot receive findings for triage — they are the highest-risk governance gap in your web attack surface.

Record your web exposure review: asset count by category, unintentional exposures identified, ownership gaps, and data sensitivity distribution. This is your Lab 1 deliverable.

Complete a web exposure review across all ten asset categories: Confirm which categories are present in your environment and which have unintentional or ungoverned exposure.

Assign owners to all unowned web-facing assets: No web-facing asset should be without an owner. Unowned public assets are the most dangerous governance gap in your environment.

Flag unintentional exposures for immediate escalation: Any asset that should not be publicly accessible but is requires same-day triage — not next week's sprint.

Knowledge Check

Why is ownership the most important governance attribute for web-facing assets?

Ownership is required for billing attribution — unowned assets cannot be included in cost center reporting.

Without an owner, findings on a web-facing asset have no recipient for triage assignment — the finding generates as an orphaned signal that no one routes or remediates. Web-facing assets with open findings and no owner represent sustained, unmanaged exposure windows.

Ownership only matters for compliance reporting — operational security teams can triage findings without knowing which team owns the asset.

Web-facing assets don't require individual ownership — they should be owned by the central security team for centralized governance.

Move on when you've completed the web exposure review and assigned owners to all unowned web-facing assets.

Web Findings & Exposure

25 min • Findings • Analyze web-related findings and prioritize by business context

Nine common web security finding categories

CloudSignals+RiskOps surfaces web security findings from cloud resource configurations — these are configuration-state findings, not runtime application vulnerability findings. Configuration-state findings are persistently present, continuously monitorable, and scanner-verifiable after remediation — which makes them more governable than runtime findings that require manual testing to detect and verify. The nine most common web security finding categories are:

Finding category	What it indicates	Typical severity
Public exposure	Storage, endpoints, or services accessible to anyone without authentication	Critical
Weak TLS / insecure transport	TLS 1.0/1.1 in use, expired certificates, or HTTP accepted on sensitive services	High
Missing logging	Access logs, audit trails, or activity monitoring disabled on web-facing services	Medium–High
Overly permissive network access	Security groups or NSGs allowing broad inbound access on web or management ports	High
Weak identity controls	MFA not enforced on admin consoles, excessive session token validity	High
Misconfigured storage	Public read/write enabled on buckets containing application or customer data	Critical
Exposed management ports	SSH, RDP, or database ports open to the internet on production systems	Critical
Missing WAF / edge protections	No WAF configured on internet-facing applications or APIs	Medium
Unreviewed third-party integrations	OAuth tokens, API connections, or webhooks to external systems without access review	Medium

In the platform — Lab 2: Web Finding Prioritization

Navigate to Findings. Filter for findings on your web-facing assets (use asset filter for internet-facing flag or filter by asset tag "public"). Review the finding count and severity distribution.

Select three findings across different web finding categories from the table above. For each, note: severity, asset category (load balancer, storage, API), data sensitivity, and business function.

Compare severity against business context. Rank the three findings by actual risk priority — not by severity alone. A High finding on a customer-facing API handling PII may rank above a Critical finding on an internal management service with no external access.

For any Public Exposure or Exposed Management Port findings (Critical tier), confirm these have same-day treatment plans — these cannot wait for the next sprint review.

Record your web finding priority list with ranked findings and rationale. This is your Lab 2 deliverable.

Complete the web finding prioritization lab: Rank your top web-facing findings using business context — severity alone is an insufficient prioritization signal for web security.

Triage all Public Exposure and Exposed Management Port findings same-day: These are direct exploitation opportunities that require immediate treatment decisions, not queue-based triage.

Confirm no recurring web findings: For any web finding that has re-emerged after a previous closure, flag it as a systemic issue requiring a project rather than a point-fix treatment plan.

Knowledge Check

What evidence supports web security assurance beyond a scanner result showing a control passes?

A penetration test report from any accredited firm within the past 24 months — this serves as the primary web security assurance artifact.

Secure architecture diagrams (showing web control points), web configuration exports (TLS settings, WAF policies, storage access policies), penetration test reports (for runtime behavior), secure code review records, CI/CD security gate results, access review records, and incident response records — together these prove web controls exist, are configured correctly, and are actively governed.

A scanner passing all CIS Benchmark checks is sufficient web security assurance evidence — no additional artifacts are required for governance purposes.

Bug bounty program activity reports — active external researcher participation demonstrates the web attack surface is being continuously tested.

Move on when you've prioritized web findings using business context and handled same-day triage for critical exposure findings.

Evidence & Controls

20 min • Evidence Fabric, Control Library • Define proof for web security governance

Web security evidence types

Web security evidence must prove that controls are configured, operate as intended, and have been reviewed by a named person with knowledge of the system. Scanner results alone satisfy the "configured" dimension — they do not satisfy "operates as intended" or "reviewed." A complete web security evidence package includes multiple artifact types linked to specific UCB controls and Assessment Objectives in the Evidence Fabric:

Secure architecture diagrams: showing web traffic flow, trust boundaries, authentication checkpoints, and WAF/CDN topology — linked to network and identity controls
Web configuration exports: TLS version and cipher configuration, storage access policies, security header settings from cloud console exports
TLS configuration reports: scan output confirming TLS 1.2+ enforced, valid certificates, no deprecated protocols
WAF policy screenshots or exports: confirming rule sets, rate limiting, and OWASP protection coverage
Penetration test reports: testing runtime application behavior (injection, authentication bypass, authorization flaws) that CSPM cannot detect
Secure code review records: documented review sign-offs for web-facing components with security findings and resolution tracking
CI/CD security gate results: SAST, DAST, or dependency scan results from pipeline runs before production deployment
Access review records: periodic confirmation that web-facing service accounts and admin access is scoped to authorized users only
Incident response records: any security event on a web-facing asset and the response taken — governance evidence of the control's ability to detect and respond

In the platform — Map evidence to web security controls

Navigate to Governance & Assurance > Evidence Fabric. Filter for evidence linked to your three anchor UCB controls from Module 1. Review what artifacts currently exist and their freshness state.

For each anchor control, identify which evidence types from the list above are present, partially present, or entirely missing. Document this as a web security evidence gap list.

Upload or link one available web security evidence artifact (TLS configuration export, WAF policy screenshot, or architecture diagram). Set: evidence type, timestamp, control linkage, AO linkage, and assign a reviewer.

After reviewer attestation, observe the AO satisfaction and confidence score change. A single well-documented artifact linked correctly to the right AO moves the dial — this is why evidence metadata matters.

Identify controls that require penetration test evidence (runtime behavior controls that scanner data cannot satisfy). Confirm a pen test is scheduled and its report will be linked to the relevant AOs upon receipt.

Build a web security evidence gap list: For each of your three anchor controls, list which evidence types are present, which are stale, and which are entirely absent.

Link and attest at least one web security artifact: Upload a real artifact, set its metadata, assign a reviewer, and observe AO satisfaction change after attestation.

Schedule pending evidence collection: For each gap in your list, create a collection task with an owner and deadline — especially for pen test and code review artifacts that require external scheduling.

Knowledge Check

When should a web security finding be escalated to a RiskOps project rather than handled as a standalone treatment plan?

All web security findings require RiskOps projects — the internet-facing nature of web assets always warrants formal project tracking.

Web findings should become RiskOps projects when remediation spans multiple teams (engineering, cloud ops, identity, vendor), requires milestone tracking over weeks or months, involves a migration or third-party dependency, needs SLA policy enforcement, or requires executive visibility into remediation progress and evidence status.

Only Critical-severity web findings require RiskOps projects — Medium and Low findings can use standalone treatment plans regardless of complexity.

Web findings automatically escalate to RiskOps projects after 7 days without a treatment decision — the platform handles escalation without manual action.

Move on when you've built your evidence gap list and linked at least one artifact with full metadata to your anchor controls.

RiskOps Remediation

25 min • Projects, Risk Treatments • Coordinate accountable web security remediation

Web security remediation often spans multiple teams

Web security remediation often spans engineering (application code), cloud operations (infrastructure configuration), identity teams (authentication and session controls), and vendor owners (third-party WAF, CDN, or SaaS platform configurations). RiskOps helps coordinate accountable work across these stakeholders — setting SLA expectations, tracking evidence requirements, and providing executive visibility without requiring manual status collection from each team.

The key governance difference between a Jira ticket and a RiskOps treatment: a RiskOps treatment has a UCB control linkage, an evidence requirement, a defined verification step, and an SLA policy timer that escalates if the finding ages past the threshold. When all four are present, web security remediation is tracked from detection to verified closure with full governance accountability.

In the platform — Lab 3: Web Security Remediation Plan

Take the highest-priority web finding from your Module 3 prioritization list. Navigate to RiskOps > Risk Treatments. Select the appropriate treatment type (Mitigate for deferred remediation with compensating control, or direct remediation).

Create the treatment record. Complete all required fields: UCB control linkage, assigned owner (the team responsible for the fix), target date aligned to your SLA policy, and evidence requirement (what scan result or configuration export confirms closure).

If the finding requires multi-team coordination (e.g., an API gateway misconfiguration that needs cloud ops + application team + security review), navigate to RiskOps > Projects and create a project with milestone-based work items for each team's contribution.

For any web finding where full remediation requires a migration (e.g., moving from HTTP to HTTPS requires application changes and load balancer reconfiguration), create a Mitigate treatment with an interim compensating control (WAF rule blocking HTTP, IP restriction) plus a remediation target date tied to the migration timeline.

Draft a two-paragraph stakeholder update: what the finding is (in business terms), what the team is doing about it, by when, and what evidence will confirm closure. This is your Lab 3 deliverable.

Create treatment records for all web-facing Critical and High findings: Every finding on an owned web-facing asset should have a treatment record with UCB linkage, owner, target date, and evidence requirement.

Use Mitigate for deferred remediation: For findings where the full fix requires a migration or external dependency, create a Mitigate treatment with a compensating control documented and a realistic remediation target date.

Draft a stakeholder update: For your highest-priority finding, write a non-technical stakeholder communication covering: what is at risk, what is being done, and when it will be resolved.

Knowledge Check

How should Vision output be validated before a web security risk narrative is distributed to executives or used as governance evidence?

Vision output drawn from current platform data can be distributed directly — it reflects live posture and doesn't require additional validation steps.

A named reviewer must verify each cited finding, metric, and risk assessment against current platform data; correct any inaccuracies or outdated metrics; add organization-specific context Vision doesn't have; attach a reviewer attestation; and include an explicit AI advisory disclaimer — before the narrative is distributed or saved as a governance artifact.

Vision outputs require validation only for external distribution — internal executive summaries can be shared directly from Vision without attestation.

Vision validation is only required when the output will be included in an external audit package — regular executive reporting does not require attestation.

Move on when treatment records are created for your top web findings and you've drafted a stakeholder communication.

Reporting & Vision

15 min • Reports, Vision • Produce governance-ready web risk summaries

Executive reporting: exposure, impact, status, residual risk

Web security reporting should avoid raw technical detail overload. Executive summaries should explain four things in business language: exposure (which internet-facing assets have open security gaps), business impact (what a successful exploitation would mean for the organization — customer data, regulatory liability, operational disruption), remediation status (what is being done, by whom, by when), and residual risk (what risk remains after compensating controls are in place and what the timeline to full remediation is). Vision can accelerate the drafting of this narrative from platform data — but requires human review before distribution.

In the platform — Produce an executive web risk summary using Vision

Navigate to Reports. Generate a posture report filtered to web-facing assets (or apply the internet-facing filter). Review: finding count by category, severity distribution, and remediation status for your top web risks.

Navigate to Vision > Ask Vision. Request a web security executive summary: "Draft an executive web risk summary covering our highest-risk public-facing exposures, business impact, current remediation status, and residual risk."

Review the Vision output against your Reports data. Verify: are the cited findings current? Are severity levels accurate? Is the business impact framing appropriate for your industry context? Correct any mischaracterizations.

Add organization-specific context: regulatory implications, specific customer impact scenarios, contractual SLA obligations for security incidents. Vision doesn't know these — only you do.

Attach your reviewer attestation and the AI advisory disclaimer. Save to the Evidence Fabric linked to the relevant UCB controls. Export and distribute the validated summary to your CISO or relevant stakeholders.

Generate a web posture report: Export a findings report filtered to web-facing assets. Review the data before using it as the basis for an executive narrative.

Draft, validate, and attest a Vision web risk narrative: Add organization-specific context, correct all inaccuracies, attach reviewer attestation and AI disclaimer before distributing.

Schedule recurring web security reporting: Set a monthly calendar entry for web posture review with your security leadership team — web attack surface changes too fast for quarterly reporting.

Knowledge Check

What makes a web security narrative appropriate for executive audiences rather than a technical audience?

Executive narratives should include full technical detail — executives need to understand the exact misconfiguration to make informed risk decisions.

Executive narratives translate technical findings into business risk language — clearly stating: what is exposed (the asset and function), what the impact would be if exploited (customer data, regulatory fines, operational disruption), what is being done about it (treatment status), and what risk remains (residual risk and timeline to full resolution).

Executive narratives should focus on remediation velocity metrics only — MTTR, findings closed per week, and SLA compliance rates are the only data executives need.

Executive narratives should include CVSS scores alongside each finding — executives need to understand the technical severity to approve remediation resources.

Move on when you've produced and attested a validated web security executive summary ready for leadership distribution.

Certification: AiVRIC Web Security Practitioner

Completing all six modules makes you eligible for the Web Security Practitioner certification exam.

Exam domain	Weight
Web security governance	20%
Web-facing asset discovery	20%
Findings and exposure analysis	25%
Evidence and controls	20%
Remediation and reporting	15%

Capstone practical scenario

A tenant has several public endpoints, one exposed storage service containing customer data, missing logging on a web workload, and unclear ownership for an API gateway. Your task:

Identify web-facing assets across all ten asset categories present in the tenant environment.
Prioritize findings using business context — explain why the priority order differs from severity-only ranking.
Map the top three findings to UCB controls and define the required evidence for each.
Recommend RiskOps remediation for the highest-priority finding — including compensating controls where full remediation is deferred.
Draft an executive web risk summary using Vision, validate it, and attest it — including AI disclaimer and organizational context.

Passing criteria: Identifies exposure and ownership gaps using the ten-asset-category framework. Prioritizes risk with business context rather than severity alone. Defines evidence linking controls to Assessment Objectives. Routes accountable remediation through RiskOps with SLA alignment. Communicates clearly to non-technical stakeholders — Vision output validated, attested, and disclaimed.

🏅

Course complete!

You've completed Web Security. Web-facing risk is now governed through your asset inventory, findings posture, UCB control evidence, and RiskOps remediation — with verified closure paths.

Explore all courses