Article

DAST for RAMP Series, part 1 of 3: Aligning DAST with RAMP Audit Requirements

05/19/2025

Introduction:
This article is part 1 of our 3-part series on using DAST to support StateRAMP and FedRAMP compliance. Here we explain how properly configured Dynamic Application Security Testing (DAST) can satisfy specific controls required for audit readiness.

Why DAST Matters for RAMP Audits:
DAST supports critical audit controls such as:

RA-5: Vulnerability Scanning
CA-7: Continuous Monitoring
SA-11: Developer Security Testing

To be audit-ready, DAST must:

Include authenticated scans for internal and external surfaces
Capture scan logs, timestamps, and evidence
Demonstrate timely remediation (via POA&M or ticketing systems)

Key Implementation Practices:

Use tools like Qualys WAS or Tenable WAS
Validate authentication using Postman or Selenium
Retain scan artifacts, logs, and remediation plans
Document scan scope and asset targeting

Auditor-Proofing Tips:

Use consistent tagging and asset naming
Create a centralized scan evidence folder
Prepare reporting in a clear, dated format

Next Up: In Part 2, we explore real-world audit risks and what causes teams to fail.

DAST for RAMP Series, part 2 of 3: Avoiding Audit Pitfalls with Proactive DAST Strategy

05/19/2025

This is part 2 of our 3-part series on RAMP compliance through DAST. Here, we identify the common issues that derail audits and how to proactively structure your DAST program to avoid them.

Common Audit Pitfalls:

Unscanned Assets: Dev/test environments missed or production-only scans
Authentication Failures: Login scripts break, token expires mid-scan
Inadequate Evidence: Missing scan logs, incomplete remediation records
Tool Misuse: Overreliance on unauthenticated scans or default templates

Proactive Solutions:

Implement scan validations and regular token testing
Automate evidence capture and storage
Tie DAST findings to POA&Ms or ticketing workflows
Establish pre-audit reviews and mock evidence walkthroughs

Strategic Advice:

Don’t rely on raw scan output alone
Normalize results and track remediation timelines
Schedule internal reviews before your 3PAO arrives

Coming in Part 3: A sustainable model for staying audit-ready year-round.

DAST for RAMP Series, part 3 of 3: Staying RAMP Audit-Ready with Continuous DAST Workflows

05/19/2025

This final entry in our 3-part series shows how to maintain ongoing compliance through scalable DAST workflows. Passing the audit is just the beginning—true success lies in year-round readiness.

Key Principles:

Consistency: Monthly or quarterly scans with tracked outcomes
Coverage: Ensure all in-scope apps and APIs are included
Documentation: Keep evidence centralized, organized, and versioned
Integration: Link DAST to ticketing, asset management, and reporting tools

Workflow Recommendations:

Schedule recurring scans with pre-defined scope
Automate token refresh and scan result archiving
Export findings directly to POA&M management systems
Flag regressions by comparing scan deltas over time

Metrics to Monitor:

Time-to-remediation
Number of assets scanned vs. in inventory
Scan success rate (auth/auth failures)
Coverage change over time

Final Takeaway:
FedRAMP and StateRAMP compliance is a moving target. But with the right DAST strategy, you can move from reactive reporting to confident, continuous compliance.

Need help implementing any of this?
Iron City Cyber specializes in tuning DAST programs for real-world audit readiness—and we’d love to help you do the same.

Why Your DAST Program Is Failing — and How to Fix It

05/03/2025

Dynamic Application Security Testing (DAST) is supposed to be your safety net — scanning live web applications for vulnerabilities before attackers find them. But for many organizations, DAST tools underdeliver: low coverage, noisy reports, and no developer buy-in. If that sounds familiar, you’re not alone — and you’re not stuck.

Here are the top reasons DAST programs fall short, and what you can do to turn things around:

1. Are You Only Scanning the Login Page?

Why it happens: Misconfigured authentication, expired tokens, or lack of automation.

How to fix it:

Use token-based flows with Postman or Selenium scripts.
Automate token generation for SAML, OAuth2, and session-based apps.
Validate access with test scans before production runs.

2. Are You Getting Flooded with False Positives?

Why it happens: Default signatures, lack of tuning, and duplicate endpoint testing.

How to fix it:

Customize severity profiles and filtering rules.
Enable vulnerability validation (e.g., Qualys QIDs, Tenable plugins).
Tag or suppress known harmless patterns.

3. Are Developers Ignoring the Findings?

Why it happens: Reports lack clarity, prioritization, or integration into developer workflows.

How to fix it:

Push findings into ticketing systems with context.
Use dev-friendly formats like JSON, GitHub issues, or JIRA tickets.
Prioritize by exploitability and business risk — not just severity.

4. Are You Skipping API Scanning?

Why it happens: APIs require authentication, headers, and input sequences that DAST tools don’t handle well out of the box.

How to fix it:

Import OpenAPI, Swagger, or Postman collections for better targeting.
Set headers and tokens dynamically before scans.
Schedule recurring API-specific scans tied to your dev cycle.

5. Do You Know What Was Actually Scanned?

Why it happens: Poor visibility into scan scope, asset tracking, and endpoint coverage.

How to fix it:

Use tagging and metadata to map apps to scans.
Run both pre-auth and post-auth scans when applicable.
Track metrics like % of pages, forms, or endpoints reached.

6. The Bigger Fix: Treat DAST as a Program, Not a Tool

Successful DAST isn’t about pressing “Scan” — it’s about building a process:

Adopt a maturity model with clear stages of improvement.
Automate workflows for repeatability and scale.
Integrate security testing into CI/CD pipelines for earlier feedback.
Measure value: time-to-fix, risk reduction, and coverage — not just scan counts.
Partner with experts who can help you tune tools like Qualys WAS and Tenable WAS to fit your environment.

Ready to Fix Your DAST Program?

If your current DAST strategy isn’t delivering real value, let’s change that. At Iron City Cyber, we help organizations turn underperforming DAST tools into developer-friendly, risk-prioritized security solutions.

Modernizing DAST: A Maturity Model for Dynamic Application Security Testing

02/12/2025

Dynamic Application Security Testing (DAST) is a critical component of any AppSec program — but for many organizations, it’s stuck at a basic level: a scan or two during release, and a PDF report no one reads. To get real value, DAST must evolve into a program that is integrated, automated, risk-aligned, and actionable.

A DAST Maturity Model helps teams assess where they are and plan a clear path forward.

DAST Maturity Model: The 5 Stages

Level 1: Ad Hoc

“We ran a scan once. It found some stuff.”

No defined process
Manual scans run sporadically
Scans often incomplete or fail authentication
No consistent ownership or reporting

Risks: Missed vulnerabilities, high false positives, low developer engagement
Goal: Establish consistent scanning and ownership

Level 2: Tool-Centric

“We scan regularly, but the tool drives the process.”

Regular scans using tools like Qualys WAS or Tenable WAS
Authentication often works, but issues persist (e.g., APIs, SPAs)
Reports are generated but not always reviewed
Developers receive PDF reports or spreadsheets

Risks: Results may not drive action. Integration is minimal.
Goal: Improve scan coverage and reporting clarity

Level 3: Process-Aware

“We’ve built repeatable processes and started tuning results.”

Scans are scheduled and scoped consistently
Auth flows are automated via Postman or Selenium
Reporting is structured and integrated (e.g., ticketing systems)
Tuning reduces false positives; developers trust findings

Strengths: Emerging collaboration between AppSec and dev teams
Goal: Align DAST with broader AppSec and dev workflows

Level 4: DevSecOps Integrated

“DAST is part of the pipeline.”

Scans triggered automatically by CI/CD events
Pre-prod environments include full scan coverage
Findings feed directly into backlog management tools (e.g., Jira)
Risk scoring, SLA tracking, and remediation metrics are in place

Benefits: Faster feedback, higher fix rates, fewer regressions
Goal: Shift security left without disrupting development velocity

Level 5: Risk-Aligned & Optimized

“We prioritize what matters, and we can prove it.”

DAST is tied to asset criticality and threat models
Vulnerabilities are prioritized using risk scores (e.g., TruRisk, exploitability context)
Scans cover UI, APIs, and microservices
Leadership sees clear metrics: time-to-remediate, coverage %, risk reduction

Benefits: High trust in security outcomes, lower exposure, regulatory confidence
Goal: Optimize and continually refine your DAST program

Using the Model: Where Are You Now?

Use this model as a self-assessment. Ask yourself:

Are we running scans or running a program?
Are we pushing PDFs or delivering prioritized risk insights?
Do devs act on findings? Do leaders understand the value?

Even moving from Level 2 to Level 3 can create immediate gains in efficiency, clarity, and security outcomes.

It’s Time to Modernize

DAST isn’t just about catching bugs — it’s about improving application security posture continuously and measurably. Whether you’re using Qualys WAS, Tenable WAS, or another platform, maturing your DAST approach unlocks better ROI, faster remediation, and stronger alignment with modern development.

Need help assessing or leveling up your DAST program?
At Iron City Cyber, we specialize in building, tuning, and scaling dynamic testing programs that work — for security, for developers, and for business leaders.

Authenticated Scanning in Modern Web Applications: Best Practices for API and Session Management

11/01/2024

Authenticated scanning is often the Achilles’ heel of DAST. You might think your scan is authenticated — but unless the scanner maintains a valid session across requests, most of your application could be invisible.

Modern web applications — especially APIs and SPAs — make it more complex than ever. Token-based flows, multi-factor logins, dynamic sessions, and non-browser endpoints all create scanning challenges. Here’s how to get it right.

1. Know Your Auth Flow Before You Scan

Start by understanding how the application authenticates users or clients:

Is it form-based login with session cookies?
Is it an API-first application using tokens (JWT, OAuth2, Bearer)?
Is MFA involved?
Does the token expire after a short time?

Tip: Map out the full flow using Postman or your browser’s developer tools before configuring your scanner.

2. For Form-Based Login: Use Browser Scripts

If the app uses traditional login forms (username/password via web UI), record the login flow using tools like:

Qualys Browser Recorder (QBR) for Selenium-based login scripts
Tenable’s GUI login recorder or scripted authentication flow

Best Practice: Test the script manually and set up post-login validation by targeting known post-auth pages.

3. For APIs: Use Header-Based Token Injection

Most modern APIs require a token in the Authorization header, often retrieved via an auth endpoint.

POST /auth/token
Body: { "username": "user", "password": "pass" }

→ Response: { "token": "abc123" }

Authorization: Bearer abc123

In Qualys WAS: Use Postman collections to model this flow.
In Tenable: Configure header injection or scripted options.

4. Automate Token Refresh

Tokens often expire in 15–60 minutes. To maintain auth:

Use pre-scan scripting to request a new token each time
Inject tokens dynamically into all scan requests
Confirm the token remains valid across the full scan session

5. Validate That the Scan Was Authenticated

Check request logs for Authorization headers or session cookies
Confirm the scan accessed authenticated-only content
In Qualys WAS, use “custom 200 OK string” to verify login success
In Tenable, review scan logs for hits on protected endpoints

6. Common Pitfalls to Avoid

Login appears to work, but session expires immediately
Scanner fails to maintain headers/cookies
Scanner gets redirected to login page and never progresses
Token injection works during test, but not in live scan

7. Consider Using Auth Staging Environments

For apps with MFA or restricted access:

Use a staging clone with simplified authentication
Pre-populate a valid session or token in the scanner
Ensure staging behavior matches production exactly

8. Align Your Auth Strategy with App Architecture

App Type	Recommended Approach
Web App (form)	Selenium login script (QBR or Tenable GUI)
API-first App	Postman collection with auth header injection
SPA (Angular/React)	Session + token combo, handled dynamically
MFA-protected App	Staging clone or dedicated service account

Conclusion: Authenticated DAST Is Worth Doing Right

Failing to scan behind login means missing the most vulnerable parts of your app. Getting authentication right — especially in API-driven and modern web apps — takes planning, scripting, and testing. But the payoff is huge: fewer blind spots, better risk visibility, and real-world assurance.

Need help getting authentication working in Qualys WAS or Tenable WAS?
At Iron City Cyber, we specialize in automating and optimizing authenticated DAST for real-world environments — no more black-box scans.