Terms and Concepts

This page defines the common terminology and concepts used by HoundDog.ai. Familiarizing yourself with these terms will help you better understand the features and capabilities of the code scanner and the Cloud Platform.

Data Elements

Data elements are the types of sensitive information that HoundDog.ai detects in code, such as Email, Social Security Number, or Auth Token. The scanner detects them from identifiers in code — class names, function names, variable names, and fields — that strongly suggest they handle sensitive data (for example User.lastName or get_ssn).

A complete list of the built-in data elements is available on GitHub: data-elements.md. You can also list them locally with hounddog data-elements list, and Enterprise organizations can customize them on the Data Elements page of the Cloud Platform.

Tags

Each data element carries one or more tags describing the kind of data:

Tag	Description
PII (Personally Identifiable Information)	Data that can identify an individual, such as full names, physical addresses, email addresses, and dates of birth.
PIFI (Personal Financial Information)	Financial data such as bank account details, credit scores, and payment history.
PHI (Protected Health Information)	Medical records, insurance information, and other health-related data as defined by regulations like HIPAA.
CHD (Cardholder Data)	Payment card information defined under PCI DSS, including the Primary Account Number (PAN), cardholder name, and expiration date. No built-in data element uses this tag — it is available for custom data elements.
SECRET	Credentials and tokens such as API keys, auth tokens, and passwords.

Sensitivity Levels

Each data element has a sensitivity level of Critical, Medium, or Low:

Sensitivity	Examples
Critical	Social Security Numbers, bank card numbers, auth tokens, medical diagnoses
Medium	IP addresses, phone numbers, gender, blood types
Low	Usernames, dates of birth, first and last names, email addresses, physical addresses

Occurrences

Data element occurrences are the specific places in code where a data element is detected, such as a variable assignment or a class field.

Data Sinks

Data sinks are destinations where data leaves its original context, such as logs, files, cookies, databases, message queues, third-party SDKs, and AI integrations. Common examples include OpenAI, Anthropic, Datadog, AWS S3, PostgreSQL, and Sentry.

• Intermediary data sinks act as channels to other data sinks, such as ORMs and HTTP clients.
• Terminal data sinks are final destinations, such as logs, databases, and third-party services.
• Data sinks can have parent-child relationships (for example, AWS is the parent of AWS S3 and AWS RDS). Filtering by a parent matches the parent and its children.

Each data sink also carries tags such as database, blob-storage, browser, third-party, intermediary, payment, ai, queue, orm, and cache, which you can use to include or exclude whole categories from scans.

A list of the built-in data sinks that have rules for Python, TypeScript, Java, C#/.NET, or Go, with per-language support, is available on GitHub: data-sinks.md. You can also list them locally with hounddog data-sinks list, and Enterprise organizations can configure them on the Data Sinks page of the Cloud Platform.

Dataflows

Dataflows are the paths that data elements take through your code to reach data sinks. The scanner traces data through assignments, transformations, string interpolations, and function calls — including across files in supported languages.

• In safe dataflows, the data reaches a sink that is marked safe for it, or the data is sanitized on the way.
• In risky dataflows (also called vulnerabilities), unsanitized sensitive data reaches an unsafe sink — for example, an email address written to a log file.

Risky dataflows are rarely intentional. They tend to emerge as codebases grow: a developer logs a full user object for debugging, or a tainted variable carries sensitive data through several transformations before landing somewhere it should not. The Dataflows page of the Cloud Platform provides a consolidated view across all scanned repositories.

Severity Levels

Each dataflow is assigned a severity of Critical, Medium, Low, or Info. Severity is derived from the sensitivity of the data elements involved and the destination sink, including any allowlist rules defined on the Data Sinks page. Safe dataflows carry the Info severity. The optional AI-powered review can adjust a dataflow’s severity or mark it as a false positive.

Sanitizers

Sanitizers are functions that transform sensitive data into a safe form — for example hashing, masking, encrypting, or redacting. When sensitive data passes through a function whose name matches a sanitizer pattern, the resulting dataflow is considered safe. See Remediation below for how to use sanitizers to fix risky dataflows, and Sanitizers for defining organization-specific patterns.

Scan Rules

Scan rules define how the scanner detects and handles data elements, data sinks, and sanitizers. Default rules ship bundled with the scanner binary. Enterprise organizations manage additional rules on the Cloud Platform under Scanner Rules; the scanner downloads and merges them with the defaults at scan time.

Privacy Risks

The following are key examples of privacy violations that HoundDog.ai detects and prevents:

Issue	Violated Frameworks	Reason for Violation
Sensitive data in logs (plaintext)	GDPR (Art. 5, 32), CCPA/CPRA, HIPAA, PCI, GLBA, PIPEDA, APPI, NIST 800-53, ISO/IEC 29100, KSA PDPL, UAE PDPL, Qatar PDPPL	Logs are ingested by monitoring and SIEM tools, so leaked sensitive data spreads quickly and is expensive to scrub retroactively.
Sensitive data in files (plaintext)	Same as above	Plaintext files significantly increase the risk of data exfiltration through lateral movement or insider theft.
Sensitive data in cookies (plaintext)	Same as above	Identifiers exposed without encryption or valid consent are clear privacy violations.
Sensitive data in local storage (plaintext)	Same as above	Local storage is accessible to client-side scripts and typically unencrypted.
Sensitive data in third-party integrations (beyond DPA)	GDPR (Art. 5, 28), CCPA/CPRA, HIPAA, PCI, GLBA, PIPEDA, APPI, NIST 800-53, ISO/IEC 29100, KSA PDPL, UAE PDPL, Qatar PDPPL	Sharing sensitive data beyond the scope of a Data Processing Agreement breaches consent and purpose-limitation rules. Applications often include hidden abstractions and SDKs that expose data to third-party services.
Sensitive data in AI integrations (beyond DPA)	GDPR (Art. 5, 28), CCPA/CPRA, HIPAA, PCI, GLBA, PIPEDA, APPI, NIST 800-53, ISO/IEC 29100, KSA PDPL, UAE PDPL, Qatar PDPPL	Sending sensitive data to AI services such as LLM providers beyond the scope of a Data Processing Agreement breaches consent and purpose-limitation rules, and prompts may be retained outside your control.

CWEs

HoundDog.ai’s mission is to shift left and empower organizations to prevent and eliminate vulnerabilities at the source-code level. These are the most common CWEs the scanner covers:

CWE	Description
CWE-201	Insertion of Sensitive Information Into Sent Data
CWE-209	Generation of Error Message Containing Sensitive Information
CWE-312	Cleartext Storage of Sensitive Information
CWE-313	Cleartext Storage in a File or on Disk
CWE-315	Cleartext Storage of Sensitive Information in a Cookie
CWE-532	Insertion of Sensitive Information into Log File
CWE-539	Use of Persistent Cookies Containing Sensitive Information
CWE-1295	Debug Messages Revealing Unnecessary Information

Remediation

Risky dataflows detected by HoundDog.ai can be fixed in one of two ways:

Code Removal

Some risky dataflows come from logging or streaming sensitive data to stdout or stderr. These are usually safe to fix by removing the logging or print statement completely. Example:

Before

# Vulnerable: printing sensitive user input
print("User email:", user_email)

After

# Fixed: logging removed completely

Data Sanitization

Other cases involve data that must remain in the code, such as sending user data to a monitoring tool like Datadog. In these situations, complete removal could cause unintended consequences, so the safer approach is to sanitize the value before use. This might involve redaction, masking, hashing, or encryption depending on the sensitivity of the data.

The scanner recognizes sanitization by the name of the function the data passes through. The built-in sanitizer rule matches a name that is exactly sanitize, mask, redact, encrypt, obfuscate, anonymize, or anonymise (lowercase), optionally followed by _ or an uppercase letter and more characters — for example sanitize(...), sanitize_user_id(...), maskEmail(...), or redactSsn(...). Matching is case-sensitive, and names such as sanitizer(...) or maskemail(...) do not match. Data that flows through a matching function is considered safe.

Before

// Vulnerable: raw user input sent to monitoring
const userId = req.body.userId;
datadog.trackEvent("login_attempt", { userId });

After

// Fixed: input passed through a sanitizer function before use
const userId = sanitize(req.body.userId);
datadog.trackEvent("login_attempt", { userId });

Enterprise organizations can define additional sanitizer patterns — for example, to recognize an in-house scrub_pii() helper — on the Sanitizers page of the Cloud Platform.

Auto-Closing Issues

Once a risky dataflow is fixed using either method, the next scan no longer detects it, and the corresponding issue is automatically closed on the Dataflows page when the results are uploaded to the Cloud Platform.