# MobileAudit Database Models: Application, Scan, Finding, Pattern, and Certificate Explained

> Understand the MobileAudit database models: Application, Scan, Finding, Pattern, and Certificate. Learn their relationships and how they form a security assessment workflow.

- Repository: [Mónica Pastor/mobileaudit](https://github.com/mpast/mobileaudit)
- Tags: api-reference
- Published: 2026-03-07

---

**The MobileAudit Django application defines five core database models—Application, Scan, Finding, Pattern, and Certificate—that establish a hierarchical security assessment workflow where users own applications, applications contain scans, scans generate findings linked to detection patterns, and scans capture APK signing certificate metadata.**

The `mpast/mobileaudit` open-source project provides a comprehensive framework for automated mobile application security analysis using Django ORM. Understanding these database models is essential for developers extending the platform, building custom integrations, or querying audit data programmatically. This guide examines the five primary models defined in [`app/models.py`](https://github.com/mpast/mobileaudit/blob/main/app/models.py) and their interconnections.

## Core Database Models in MobileAudit

### Application Model

The **Application** model represents a mobile app targeted for security auditing. Defined in [`app/models.py`](https://github.com/mpast/mobileaudit/blob/main/app/models.py), it stores metadata including `name`, `description`, and ownership via a `user` foreign key to Django's built-in User model.

Each application serves as the parent container for multiple scan instances, establishing a one-to-many relationship through the `Scan.app` foreign key. When an application is deleted, Django's cascade behavior removes all associated scans automatically.

### Scan Model

The **Scan** model captures a single analysis run, typically representing an uploaded APK file for a specific application version. Key fields include `app` (foreign key to Application), `apk` (file field), `status`, `progress`, and `user`.

According to the source code in [`app/models.py`](https://github.com/mpast/mobileaudit/blob/main/app/models.py), the Scan model defines the relationship as `app = models.ForeignKey(Application, on_delete=models.CASCADE)`, ensuring that deleting an application removes its scans. Each scan generates child records including Findings, Certificates, Permissions, and Components discovered during static analysis.

### Finding Model

The **Finding** model represents concrete security issues discovered in the APK, such as hardcoded credentials or insecure API usage. Critical fields include `scan` (foreign key), `type` (optional link to Pattern), `cwe` (foreign key to CWE), `risk` (optional foreign key), `severity`, `status`, and location metadata (`path`, `line_number`).

As implemented in [`app/models.py`](https://github.com/mpast/mobileaudit/blob/main/app/models.py), findings link to scans via `scan = models.ForeignKey(Scan, on_delete=models.CASCADE)` and optionally reference the generating rule through `type = models.ForeignKey(Pattern, blank=True, null=True)`. This design allows findings to exist independently while maintaining traceability to detection rules when applicable.

### Pattern Model

The **Pattern** model defines generic detection rules that can generate findings. It stores `default_cwe`, `default_risk`, `default_name`, `default_severity`, and the actual `pattern` (regex or string match).

In [`app/models.py`](https://github.com/mpast/mobileaudit/blob/main/app/models.py), patterns reference weakness classifications via `default_cwe = models.ForeignKey(Cwe, on_delete=models.CASCADE)` and impact scoring via `default_risk = models.ForeignKey(Risk, null=True)`. These defaults propagate to findings when the pattern generates a match, ensuring consistent vulnerability classification.

### Certificate Model

The **Certificate** model stores signing certificate metadata extracted from APKs during scanning. Fields include `scan` (foreign key), `version`, `sha1`, `sha256`, `issuer`, and `subject`.

The model connects to scans through `scan = models.ForeignKey(Scan, on_delete=models.CASCADE)` as defined in [`app/models.py`](https://github.com/mpast/mobileaudit/blob/main/app/models.py), ensuring certificate data is automatically removed when parent scans are deleted.

## Model Relationships and Data Flow

The MobileAudit database models establish a strict hierarchical ownership structure that mirrors the security assessment workflow:

- **User → Application**: Each application belongs to a specific user through the `user` foreign key, enabling multi-tenant isolation.
- **Application → Scan**: Applications contain multiple scans representing different analysis runs or versions, linked via `Scan.app`.
- **Scan → Finding**: Each scan generates multiple findings, connected through `Finding.scan`.
- **Finding → Pattern**: Findings optionally link to detection rules via `Finding.type`, allowing traceability from vulnerability to rule.
- **Scan → Certificate**: Certificate metadata ties directly to scans through `Certificate.scan`.

This architecture ensures referential integrity while supporting complex queries such as retrieving all findings for a specific application across multiple scans, or identifying which patterns generate the most high-severity vulnerabilities.

## Working with MobileAudit Database Models: Code Examples

The following examples demonstrate standard CRUD operations using the MobileAudit Django ORM. These assume imports from `app.models` and access to a `request.user` object.

### Creating an Application

```python
from app.models import Application

app = Application.objects.create(
    name="MyCoolApp",
    description="A sample mobile app for security testing",
    user=request.user,
)

```

### Starting a Scan

```python
from app.models import Scan

scan = Scan.objects.create(
    app=app,
    name="Initial analysis",
    apk=my_uploaded_file,  # Django InMemoryUploadedFile

    description="First scan of v1.0",
    user=request.user,
    status="Pending",
)

```

### Defining a Pattern

```python
from app.models import Pattern, Cwe, Risk, Severity

cwe = Cwe.objects.get_or_create(
    cwe=79, 
    defaults={'description': 'Improper Neutralization of Input'}
)[0]

risk = Risk.objects.get_or_create(
    risk=3, 
    defaults={'description': 'High impact', 'reference': ''}
)[0]

pattern = Pattern.objects.create(
    default_cwe=cwe,
    default_risk=risk,
    default_name="Insecure HTTP usage",
    default_severity=Severity.HI,
    pattern=r'http://',
)

```

### Recording a Finding

```python
from app.models import Finding, Status

finding = Finding.objects.create(
    scan=scan,
    type=pattern,  # optional link to the generating rule

    name="Hard-coded HTTP URL",
    path="src/com/example/network/Api.java",
    line_number=42,
    line='String url = "http://example.com/api";',
    snippet='String url = "http://example.com/api";',
    status=Status.VF,
    severity=Severity.HI,
    description="The app uses clear-text HTTP which can be intercepted.",
    cwe=cwe,
    risk=risk,
    user=request.user,
)

```

### Storing a Certificate

```python
from app.models import Certificate

cert = Certificate.objects.create(
    scan=scan,
    version="v1",
    sha1="A1B2C3D4E5F6...",
    sha256="0123456789ABCDEF...",
    issuer="CN=Example CA, O=Example Org",
    subject="CN=Example App, O=Example Org",
)

```

## Key Source Files

The MobileAudit database models and their relationships are implemented across these critical files in the repository:

- **[`app/models.py`](https://github.com/mpast/mobileaudit/blob/main/app/models.py)** – Contains all core ORM definitions including **Application**, **Scan**, **Finding**, **Pattern**, and **Certificate**, plus supporting lookup tables (**CWE**, **Risk**, **Severity**, **Status**).
- **[`app/serializers.py`](https://github.com/mpast/mobileaudit/blob/main/app/serializers.py)** – Django REST Framework serializers exposing the core models via API endpoints for frontend integration.
- **[`app/views.py`](https://github.com/mpast/mobileaudit/blob/main/app/views.py)** – ViewSets and API endpoints orchestrating scan creation, finding retrieval, and model relationship management.
- **[`manage.py`](https://github.com/mpast/mobileaudit/blob/main/manage.py)** and **[`app/config/settings.py`](https://github.com/mpast/mobileaudit/blob/main/app/config/settings.py)** – Standard Django bootstrap files required for migrations and development server operations.

## Summary

- **Application**, **Scan**, **Finding**, **Pattern**, and **Certificate** constitute the five core database models in the MobileAudit Django application.
- The hierarchical data flow follows **User** → **Application** → **Scan** → **Finding**, with **Pattern** providing rule definitions and **Certificate** storing APK signing metadata.
- **ForeignKey** relationships in [`app/models.py`](https://github.com/mpast/mobileaudit/blob/main/app/models.py) enforce referential integrity: `Scan.app`, `Finding.scan`, `Finding.type`, `Certificate.scan`, and `Pattern.default_cwe`.
- Practical CRUD operations follow standard Django ORM patterns, enabling security teams to programmatically create audits, record vulnerabilities, and extract certificate data.

## Frequently Asked Questions

### What is the relationship between Scan and Application in MobileAudit?

The **Scan** model maintains a many-to-one relationship with **Application** through the `app` foreign key defined in [`app/models.py`](https://github.com/mpast/mobileaudit/blob/main/app/models.py). Each application can have multiple scans representing different analysis runs or APK versions, while each scan belongs to exactly one application. The relationship uses `on_delete=models.CASCADE`, meaning deleting an application automatically removes its associated scans and their child records.

### How does the Finding model link to security rules and classifications?

The **Finding** model connects to detection rules through the optional `type` foreign key that references the **Pattern** model, allowing traceability from a discovered vulnerability back to the specific rule that generated it. Additionally, findings reference **CWE** (Common Weakness Enumeration) entries via the required `cwe` field and optionally link to **Risk** records for impact scoring, creating a comprehensive classification system for each vulnerability discovered during analysis.

### Where are the database models defined in the MobileAudit repository?

All core database models—including **Application**, **Scan**, **Finding**, **Pattern**, and **Certificate**—are defined in [`app/models.py`](https://github.com/mpast/mobileaudit/blob/main/app/models.py) within the MobileAudit repository. This file also contains supporting enumeration models such as **CWE**, **Risk**, **Severity**, and **Status** that provide standardized classification values. The models use standard Django ORM fields including `ForeignKey`, `CharField`, and `TextField` to establish relationships and store audit data according to the application's security assessment workflow.

### Can Patterns exist without associated Findings in MobileAudit?

Yes, **Pattern** records can exist independently of **Finding** records. The relationship is unidirectional and optional from the finding side—the **Finding** model's `type` field accepts `blank=True, null=True`, meaning findings can be created without linking to a pattern. This design supports manual finding creation, imports from external security tools, or findings generated by custom analysis engines while maintaining the ability to trace automated detections back to their originating rules when applicable.