feat: refine all LLM system prompts for precision and reduced false positives #49
BIN
CERTifAI_Investor_OnePager_DE.pdf
Normal file
BIN
CERTifAI_Investor_OnePager_EN.pdf
Normal file
@@ -11,9 +11,18 @@ Rules:
|
||||
- The fix must be a drop-in replacement for the vulnerable code
|
||||
|
|
||||
- Preserve the original code's style, indentation, and naming conventions
|
||||
- Add at most one brief inline comment on the changed line explaining the security fix
|
||||
- If the fix requires importing a new module, include the import statement on a separate line prefixed with "// Add import: "
|
||||
- If the fix requires importing a new module, include the import on a separate line prefixed with the language's comment syntax + "Add import: "
|
||||
- Do not refactor, rename variables, or "improve" unrelated code
|
||||
- If the vulnerability is a false positive and the code is actually safe, return the original code unchanged with a comment "// No fix needed: <reason>""#;
|
||||
- If the vulnerability is a false positive and the code is actually safe, return the original code unchanged with a comment explaining why no fix is needed
|
||||
|
||||
Language-specific fix guidance:
|
||||
- Rust: use `?` for error propagation, prefer `SecretString` for secrets, use parameterized queries with `sqlx`/`diesel`
|
||||
- Python: use parameterized queries (never f-strings in SQL), use `secrets` module not `random`, use `subprocess.run([...])` list form, use `markupsafe.escape()` for HTML
|
||||
sharang
commented
[medium] Inconsistent Error Handling in Fix Generation The Suggested fix: Add explicit error handling for potential parsing/validation failures from the LLM response to ensure consistent error management. *Scanner: code-review/convention | * **[medium] Inconsistent Error Handling in Fix Generation**
The `suggest_fix` function in `compliance-agent/src/llm/fixes.rs` returns a `Result<String, AgentError>` but doesn't explicitly handle potential parsing or validation errors from the LLM response, which could lead to unhandled exceptions.
Suggested fix: Add explicit error handling for potential parsing/validation failures from the LLM response to ensure consistent error management.
*Scanner: code-review/convention | *
<!-- compliance-fp:a60d6afa0b89adef592638aa134966150689b332afeef9d6c034363f324d3886 -->
|
||||
- Go: use `sql.Query` with `$1`/`?` placeholders, use `crypto/rand` not `math/rand`, use `html/template` not `text/template`, return errors don't panic
|
||||
- Java/Kotlin: use `PreparedStatement` with `?` params, use `SecureRandom`, use `Jsoup.clean()` for HTML sanitization, use `@Valid` for input validation
|
||||
- Ruby: use ActiveRecord parameterized finders, use `SecureRandom`, use `ERB::Util.html_escape`, use `strong_parameters`
|
||||
- PHP: use PDO prepared statements with `:param` or `?`, use `random_bytes()`/`random_int()`, use `htmlspecialchars()` with `ENT_QUOTES`, use `password_hash(PASSWORD_BCRYPT)`
|
||||
- C/C++: use `snprintf` not `sprintf`, use bounds-checked APIs, free resources in reverse allocation order, use `memset_s` for secret cleanup"#;
|
||||
|
||||
pub async fn suggest_fix(llm: &Arc<LlmClient>, finding: &Finding) -> Result<String, AgentError> {
|
||||
let user_prompt = format!(
|
||||
|
||||
@@ -15,9 +15,17 @@ Do NOT report:
|
||||
- Style, naming, formatting, documentation, or code organization preferences
|
||||
|
sharang
commented
[medium] Missing CWE field in logic review prompt response format The LOGIC_REVIEW_PROMPT specifies a JSON response format that includes 'cwe' field, but the example response format doesn't include this field. This inconsistency may cause parsing issues. Suggested fix: Either remove 'cwe' from the specification or update the example response format to include the 'cwe' field consistently *Scanner: code-review/convention | * **[medium] Missing CWE field in logic review prompt response format**
The LOGIC_REVIEW_PROMPT specifies a JSON response format that includes 'cwe' field, but the example response format doesn't include this field. This inconsistency may cause parsing issues.
Suggested fix: Either remove 'cwe' from the specification or update the example response format to include the 'cwe' field consistently
*Scanner: code-review/convention | *
<!-- compliance-fp:b37f6efba86e1be106cbe85fac06df3b1221cd52de446c1a0fe625923929c1e7 -->
sharang
commented
[medium] Missing CWE field in logic review prompt response format The LOGIC_REVIEW_PROMPT specifies a JSON response format that includes 'cwe' field, but the example response format doesn't include this field. This inconsistency may cause parsing issues. Suggested fix: Either remove 'cwe' from the specification or update the example response format to include the 'cwe' field consistently *Scanner: code-review/convention | * **[medium] Missing CWE field in logic review prompt response format**
The LOGIC_REVIEW_PROMPT specifies a JSON response format that includes 'cwe' field, but the example response format doesn't include this field. This inconsistency may cause parsing issues.
Suggested fix: Either remove 'cwe' from the specification or update the example response format to include the 'cwe' field consistently
*Scanner: code-review/convention | *
<!-- compliance-fp:b37f6efba86e1be106cbe85fac06df3b1221cd52de446c1a0fe625923929c1e7 -->
|
||||
- Theoretical issues without a concrete triggering scenario
|
||||
- "Potential" problems that require assumptions not supported by the visible code
|
||||
|
sharang
commented
[medium] Overly complex boolean expressions in security review prompt The SECURITY_REVIEW_PROMPT contains extremely long and complex boolean expressions that make it difficult to reason about the conditions for what constitutes a vulnerability. This increases the risk of misinterpreting the rules and potentially flagging non-issues or missing actual vulnerabilities. Suggested fix: Break down the complex boolean expressions into simpler conditional statements or use helper functions to encapsulate the logic. Consider using a structured format like bullet points or tables to represent the complex conditions. *Scanner: code-review/complexity | * **[medium] Overly complex boolean expressions in security review prompt**
The SECURITY_REVIEW_PROMPT contains extremely long and complex boolean expressions that make it difficult to reason about the conditions for what constitutes a vulnerability. This increases the risk of misinterpreting the rules and potentially flagging non-issues or missing actual vulnerabilities.
Suggested fix: Break down the complex boolean expressions into simpler conditional statements or use helper functions to encapsulate the logic. Consider using a structured format like bullet points or tables to represent the complex conditions.
*Scanner: code-review/complexity | *
<!-- compliance-fp:759b111f257dd8377e94632d4f69aa221c87aa6b34b9897d4893b5b14d72e4d2 -->
sharang
commented
[medium] Overly complex boolean expressions in security review prompt The SECURITY_REVIEW_PROMPT contains extremely long and complex boolean expressions that make it difficult to reason about the conditions for what constitutes a vulnerability. This increases the risk of misinterpreting the rules and potentially flagging non-issues or missing actual vulnerabilities. Suggested fix: Break down the complex boolean expressions into simpler conditional statements or use helper functions to encapsulate the logic. Consider using a structured format like bullet points or tables to represent the complex conditions. *Scanner: code-review/complexity | * **[medium] Overly complex boolean expressions in security review prompt**
The SECURITY_REVIEW_PROMPT contains extremely long and complex boolean expressions that make it difficult to reason about the conditions for what constitutes a vulnerability. This increases the risk of misinterpreting the rules and potentially flagging non-issues or missing actual vulnerabilities.
Suggested fix: Break down the complex boolean expressions into simpler conditional statements or use helper functions to encapsulate the logic. Consider using a structured format like bullet points or tables to represent the complex conditions.
*Scanner: code-review/complexity | *
<!-- compliance-fp:759b111f257dd8377e94632d4f69aa221c87aa6b34b9897d4893b5b14d72e4d2 -->
|
||||
- Language-idiomatic patterns (e.g. Rust's `||` short-circuit evaluation, variable shadowing, `impl` patterns)
|
||||
- Complexity or function length — that's a separate review pass
|
||||
|
||||
Language-idiomatic patterns that are NOT bugs (do not flag these):
|
||||
- Rust: `||`/`&&` short-circuit evaluation, variable shadowing, `let` rebinding, `clone()`, `impl` blocks, `match` arms with guards, `?` operator chaining, `unsafe` blocks with safety comments
|
||||
- Python: duck typing, EAFP pattern (try/except vs check-first), `*args`/`**kwargs`, walrus operator `:=`, truthiness checks on containers, bare `except:` in top-level handlers
|
||||
- Go: multiple return values for errors, `if err != nil` patterns, goroutine + channel patterns, blank identifier `_`, named returns, `defer` for cleanup, `init()` functions
|
||||
- Java/Kotlin: checked exception patterns, method overloading, `Optional` vs null checks, Kotlin `?.` safe calls, `!!` non-null assertions in tests, `when` exhaustive matching, companion objects, `lateinit`
|
||||
- Ruby: monkey patching in libraries, method_missing, blocks/procs/lambdas, `rescue => e` patterns, `send`/`respond_to?` metaprogramming, `nil` checks via `&.` safe navigation
|
||||
- PHP: loose comparisons with `==` (only flag if `===` was clearly intended), `@` error suppression in legacy code, `isset()`/`empty()` patterns, magic methods (`__get`, `__call`), array functions as callbacks
|
||||
- C/C++: RAII patterns, move semantics, `const_cast`/`static_cast` in appropriate contexts, macro usage for platform compat, pointer arithmetic in low-level code, `goto` for cleanup in C
|
||||
|
sharang
commented
[medium] Incorrect severity level in SECURITY_REVIEW_PROMPT The SECURITY_REVIEW_PROMPT uses 'critical' severity for vulnerabilities that could lead to remote code execution, auth bypass, or data breach with no preconditions, but the description says 'no preconditions' which contradicts the typical definition of 'critical' severity that requires minimal preconditions. This inconsistency may mislead reviewers about what constitutes a critical vulnerability. Suggested fix: Clarify the criteria for 'critical' severity in the description to match the actual requirements. Either change the description to say 'minimal preconditions' or adjust the severity mapping to be consistent. *Scanner: code-review/logic | * **[medium] Incorrect severity level in SECURITY_REVIEW_PROMPT**
The SECURITY_REVIEW_PROMPT uses 'critical' severity for vulnerabilities that could lead to remote code execution, auth bypass, or data breach with no preconditions, but the description says 'no preconditions' which contradicts the typical definition of 'critical' severity that requires minimal preconditions. This inconsistency may mislead reviewers about what constitutes a critical vulnerability.
Suggested fix: Clarify the criteria for 'critical' severity in the description to match the actual requirements. Either change the description to say 'minimal preconditions' or adjust the severity mapping to be consistent.
*Scanner: code-review/logic | *
<!-- compliance-fp:94ef4ae9b361a8f1529f1b4acf5adfa57887f45d95f7cb3e718e7193a4a87d92 -->
sharang
commented
[medium] Incorrect severity level in SECURITY_REVIEW_PROMPT The SECURITY_REVIEW_PROMPT uses 'critical' severity for vulnerabilities that could lead to remote code execution, auth bypass, or data breach with no preconditions, but the description says 'no preconditions' which contradicts the typical definition of 'critical' severity that requires minimal preconditions. This inconsistency may mislead reviewers about what constitutes a critical vulnerability. Suggested fix: Clarify the criteria for 'critical' severity in the description to match the actual requirements. Either change the description to say 'minimal preconditions' or adjust the severity mapping to be consistent. *Scanner: code-review/logic | * **[medium] Incorrect severity level in SECURITY_REVIEW_PROMPT**
The SECURITY_REVIEW_PROMPT uses 'critical' severity for vulnerabilities that could lead to remote code execution, auth bypass, or data breach with no preconditions, but the description says 'no preconditions' which contradicts the typical definition of 'critical' severity that requires minimal preconditions. This inconsistency may mislead reviewers about what constitutes a critical vulnerability.
Suggested fix: Clarify the criteria for 'critical' severity in the description to match the actual requirements. Either change the description to say 'minimal preconditions' or adjust the severity mapping to be consistent.
*Scanner: code-review/logic | *
<!-- compliance-fp:94ef4ae9b361a8f1529f1b4acf5adfa57887f45d95f7cb3e718e7193a4a87d92 -->
|
||||
|
||||
Severity guide:
|
||||
- high: Will cause incorrect behavior in normal usage
|
||||
- medium: Will cause incorrect behavior in edge cases
|
||||
@@ -47,9 +55,18 @@ Do NOT report:
|
||||
- Logging of non-sensitive operational data (finding titles, counts, performance metrics)
|
||||
- "Information disclosure" for data that is already public or user-facing
|
||||
- Code style, performance, or general quality issues
|
||||
- Missing validation on internal function parameters (trust the caller within the same crate)
|
||||
- Missing validation on internal function parameters (trust the caller within the same module/crate/package)
|
||||
- Theoretical attacks that require preconditions not present in the code
|
||||
|
||||
Language-specific patterns that are NOT vulnerabilities (do not flag these):
|
||||
- Python: `pickle` used on trusted internal data, `eval()`/`exec()` on hardcoded strings, `subprocess` with hardcoded commands, Django `mark_safe()` on static content, `assert` in non-security contexts
|
||||
- Go: `crypto/rand` is secure (don't confuse with `math/rand`), `sql.DB` with parameterized queries is safe, `http.ListenAndServe` without TLS in dev/internal, error strings in responses (Go convention)
|
||||
- Java/Kotlin: Spring Security annotations are sufficient auth checks, `@Transactional` provides atomicity, JPA parameterized queries are safe, Kotlin `require()`/`check()` are assertion patterns not vulnerabilities
|
||||
- Ruby: Rails `params.permit()` is input validation, `render html:` with `html_safe` on generated content, ActiveRecord parameterized finders are safe, Devise/Warden patterns for auth
|
||||
- PHP: PDO prepared statements are safe, Laravel Eloquent is parameterized, `htmlspecialchars()` is XSS mitigation, Symfony security voters are auth checks, `password_hash()`/`password_verify()` are correct bcrypt usage
|
||||
- C/C++: `strncpy`/`snprintf` are bounds-checked (vs `strcpy`/`sprintf`), smart pointers manage memory, RAII handles cleanup, `static_assert` is compile-time only, OpenSSL with proper context setup
|
||||
- Rust: `sha2`/`blake3` for fingerprinting is not "weak crypto", `unsafe` with documented invariants, `secrecy::SecretString` properly handles secrets
|
||||
|
||||
Severity guide:
|
||||
- critical: Remote code execution, auth bypass, or data breach with no preconditions
|
||||
- high: Exploitable vulnerability requiring minimal preconditions
|
||||
@@ -73,9 +90,17 @@ Do NOT report:
|
||||
- Style preferences, formatting, naming conventions, or documentation
|
||||
- Code organization suggestions ("this function should be split")
|
||||
- Patterns that are valid in the language even if you'd write them differently
|
||||
- Rust-specific: variable shadowing, `||`/`&&` short-circuit, `let` rebinding, builder patterns, `clone()` usage
|
||||
- "Missing type annotations" unless the code literally won't compile or causes a type inference bug
|
||||
|
||||
Language-specific patterns that are conventional (do not flag these):
|
||||
- Rust: variable shadowing, `||`/`&&` short-circuit, `let` rebinding, builder patterns, `clone()`, `From`/`Into` impl chains, `#[allow(...)]` attributes
|
||||
- Python: `**kwargs` forwarding, `@property` setters, `__dunder__` methods, list comprehensions with conditions, `if TYPE_CHECKING` imports, `noqa` comments
|
||||
- Go: stuttering names (`http.HTTPClient`) discouraged but not a bug, `context.Context` as first param, init() functions, `//nolint` directives, returning concrete types vs interfaces in internal code
|
||||
- Java/Kotlin: builder pattern boilerplate, Lombok annotations (`@Data`, `@Builder`), Kotlin data classes, `companion object` factories, `@Suppress` annotations, checked exception wrapping
|
||||
- Ruby: `attr_accessor` usage, `Enumerable` mixin patterns, `module_function`, `class << self` syntax, DSL blocks (Rake, RSpec, Sinatra routes)
|
||||
- PHP: `__construct` with property promotion, Laravel facades, static factory methods, nullable types with `?`, attribute syntax `#[...]`
|
||||
- C/C++: header guards vs `#pragma once`, forward declarations, `const` correctness patterns, template specialization, `auto` type deduction
|
||||
|
||||
Severity guide:
|
||||
- medium: Convention violation that will likely cause a bug or maintenance problem
|
||||
- low: Convention violation that is a minor concern
|
||||
|
||||
@@ -17,13 +17,23 @@ Actions:
|
||||
- "dismiss": False positive, not exploitable, or not actionable. Remove it.
|
||||
|
||||
|
sharang
commented
[high] Incorrect JSON response format in triage system prompt The updated TRIAGE_SYSTEM_PROMPT removes markdown fences from the JSON response example, but the actual implementation may still expect or produce fenced JSON. This could cause parsing failures when the LLM returns properly formatted JSON without the markdown fences. Suggested fix: Ensure the LLM client parsing logic correctly handles both fenced and unfenced JSON responses, or update the prompt to explicitly mention that markdown fences should be omitted from the actual response. *Scanner: code-review/logic | * **[high] Incorrect JSON response format in triage system prompt**
The updated TRIAGE_SYSTEM_PROMPT removes markdown fences from the JSON response example, but the actual implementation may still expect or produce fenced JSON. This could cause parsing failures when the LLM returns properly formatted JSON without the markdown fences.
Suggested fix: Ensure the LLM client parsing logic correctly handles both fenced and unfenced JSON responses, or update the prompt to explicitly mention that markdown fences should be omitted from the actual response.
*Scanner: code-review/logic | *
<!-- compliance-fp:4a46aba3b15a83b61730e3f707a542850eaf202ff158e71004fcc9c024f82dff -->
|
||||
Dismiss when:
|
||||
- The scanner flagged a language idiom as a bug (e.g. Rust short-circuit `||`, variable shadowing, `clone()`)
|
||||
- The scanner flagged a language idiom as a bug (see examples below)
|
||||
- The finding is in test/example/generated/vendored code
|
||||
- The "vulnerability" requires preconditions that don't exist in the code
|
||||
- The finding is about code style, complexity, or theoretical concerns rather than actual bugs
|
||||
- A hash function is used for non-security purposes (dedup, caching, content addressing)
|
||||
- Internal logging of non-sensitive operational data is flagged as "information disclosure"
|
||||
|
sharang
commented
[medium] Incorrect JSON response format in triage system prompt The updated TRIAGE_SYSTEM_PROMPT removes markdown fences (```json) from the expected JSON response format, but the prompt text still mentions 'no markdown fences' which could confuse LLM interpretation. More importantly, the instruction says to respond with a JSON array but doesn't specify that the response should be valid JSON without any additional text or formatting. Suggested fix: Clarify that the response should be pure JSON without any markdown fences or extra text, and consider adding explicit examples of valid responses to avoid ambiguity. *Scanner: code-review/logic | * **[medium] Incorrect JSON response format in triage system prompt**
The updated TRIAGE_SYSTEM_PROMPT removes markdown fences (```json) from the expected JSON response format, but the prompt text still mentions 'no markdown fences' which could confuse LLM interpretation. More importantly, the instruction says to respond with a JSON array but doesn't specify that the response should be valid JSON without any additional text or formatting.
Suggested fix: Clarify that the response should be pure JSON without any markdown fences or extra text, and consider adding explicit examples of valid responses to avoid ambiguity.
*Scanner: code-review/logic | *
<!-- compliance-fp:306961418f1c49dd102048ec3283e2740ead0e804ad956e24abf9dd61de0a9c6 -->
sharang
commented
[medium] Incorrect JSON response format in triage system prompt The updated TRIAGE_SYSTEM_PROMPT removes markdown fences (```json) from the expected JSON response format, but the prompt text still mentions 'no markdown fences' which could confuse LLM interpretation. More importantly, the instruction says to respond with a JSON array but doesn't specify that the response should be valid JSON without any additional text or formatting. Suggested fix: Clarify that the response should be pure JSON without any markdown fences or extra text, and consider adding explicit examples of valid responses to avoid ambiguity. *Scanner: code-review/logic | * **[medium] Incorrect JSON response format in triage system prompt**
The updated TRIAGE_SYSTEM_PROMPT removes markdown fences (```json) from the expected JSON response format, but the prompt text still mentions 'no markdown fences' which could confuse LLM interpretation. More importantly, the instruction says to respond with a JSON array but doesn't specify that the response should be valid JSON without any additional text or formatting.
Suggested fix: Clarify that the response should be pure JSON without any markdown fences or extra text, and consider adding explicit examples of valid responses to avoid ambiguity.
*Scanner: code-review/logic | *
<!-- compliance-fp:306961418f1c49dd102048ec3283e2740ead0e804ad956e24abf9dd61de0a9c6 -->
|
||||
- The finding duplicates another finding already in the list
|
||||
- Framework-provided security is already in place (e.g. ORM parameterized queries, CSRF middleware, auth decorators)
|
||||
|
||||
Common false positive patterns by language (dismiss these):
|
||||
- Rust: short-circuit `||`/`&&`, variable shadowing, `clone()`, `unsafe` with safety docs, `sha2` for fingerprinting
|
||||
- Python: EAFP try/except, `subprocess` with hardcoded args, `pickle` on trusted data, Django `mark_safe` on static content
|
||||
- Go: `if err != nil` is not "swallowed error", `crypto/rand` is secure, returning errors is not "information disclosure"
|
||||
- Java/Kotlin: Spring Security annotations are valid auth, JPA parameterized queries are safe, Kotlin `!!` in tests is fine
|
||||
- Ruby: Rails `params.permit` is validation, ActiveRecord finders are parameterized, `html_safe` on generated content
|
||||
- PHP: PDO prepared statements are safe, Laravel Eloquent is parameterized, `htmlspecialchars` is XSS mitigation
|
||||
|
sharang
commented
[medium] Inconsistent error handling pattern in triage_findings The triage_findings function uses ? operator for error propagation but doesn't handle the case where the LLM response parsing might fail. The function signature suggests it returns Result<(), Box>, but there's no explicit error handling for parsing failures from the LLM response. Suggested fix: Add explicit error handling for LLM response parsing failures and ensure consistent error propagation throughout the function. *Scanner: code-review/convention | * **[medium] Inconsistent error handling pattern in triage_findings**
The triage_findings function uses ? operator for error propagation but doesn't handle the case where the LLM response parsing might fail. The function signature suggests it returns Result<(), Box<dyn std::error::Error>>, but there's no explicit error handling for parsing failures from the LLM response.
Suggested fix: Add explicit error handling for LLM response parsing failures and ensure consistent error propagation throughout the function.
*Scanner: code-review/convention | *
<!-- compliance-fp:31fde056984dd98fa386b3c998ea14fee8ffdb9fe8c682a72efa1135336d6b28 -->
sharang
commented
[medium] Inconsistent error handling pattern in triage_findings The triage_findings function uses ? operator for error propagation but doesn't handle the case where the LLM response parsing might fail. The function signature suggests it returns Result<(), Box>, but there's no explicit error handling for parsing failures from the LLM response. Suggested fix: Add explicit error handling for LLM response parsing failures and ensure consistent error propagation throughout the function. *Scanner: code-review/convention | * **[medium] Inconsistent error handling pattern in triage_findings**
The triage_findings function uses ? operator for error propagation but doesn't handle the case where the LLM response parsing might fail. The function signature suggests it returns Result<(), Box<dyn std::error::Error>>, but there's no explicit error handling for parsing failures from the LLM response.
Suggested fix: Add explicit error handling for LLM response parsing failures and ensure consistent error propagation throughout the function.
*Scanner: code-review/convention | *
<!-- compliance-fp:31fde056984dd98fa386b3c998ea14fee8ffdb9fe8c682a72efa1135336d6b28 -->
|
||||
- C/C++: `strncpy`/`snprintf` are bounds-checked, smart pointers manage memory, RAII handles cleanup
|
||||
|
||||
Confirm only when:
|
||||
- You can describe a concrete scenario where the bug manifests or the vulnerability is exploitable
|
||||
|
||||
419
onepager_de.html
Normal file
@@ -0,0 +1,419 @@
|
||||
<!DOCTYPE html>
|
||||
|
sharang
commented
[medium] Excessive HTML file length The HTML file contains 419 lines of code which is significantly longer than typical single-file components. This makes it difficult to maintain and understand the overall structure. Suggested fix: Consider breaking this into smaller components or using a templating system to manage the complexity. The file should be split into separate HTML partials or a component-based approach. *Scanner: code-review/complexity | * **[medium] Excessive HTML file length**
The HTML file contains 419 lines of code which is significantly longer than typical single-file components. This makes it difficult to maintain and understand the overall structure.
Suggested fix: Consider breaking this into smaller components or using a templating system to manage the complexity. The file should be split into separate HTML partials or a component-based approach.
*Scanner: code-review/complexity | *
<!-- compliance-fp:73968b39015f45b0b36bdde91804632583a4f2aba1db7d6097a1d2d302761096 -->
sharang
commented
[medium] Missing type annotations in HTML template The HTML file contains embedded CSS and JavaScript but lacks type annotations for any JavaScript functions or variables that might be present. This could lead to runtime issues if JavaScript is added later without proper typing. Suggested fix: Add type annotations to any JavaScript code present in the file, or ensure that any dynamic behavior is properly typed if using TypeScript. *Scanner: code-review/convention | * **[medium] Missing type annotations in HTML template**
The HTML file contains embedded CSS and JavaScript but lacks type annotations for any JavaScript functions or variables that might be present. This could lead to runtime issues if JavaScript is added later without proper typing.
Suggested fix: Add type annotations to any JavaScript code present in the file, or ensure that any dynamic behavior is properly typed if using TypeScript.
*Scanner: code-review/convention | *
<!-- compliance-fp:a106188cfa99eb552c4818efb2ba2eadb75b716fce6552b36e02a3dc56b2c252 -->
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>CERTifAI — Investor One-Pager</title>
|
||||
<link href="https://fonts.googleapis.com/css2?family=Plus+Jakarta+Sans:wght@300;400;500;600;700;800&display=swap" rel="stylesheet">
|
||||
<style>
|
||||
@page { size: A4; margin: 0; }
|
||||
* { margin: 0; padding: 0; box-sizing: border-box; }
|
||||
|
sharang
commented
[medium] Incorrect CSS media query for print The CSS uses Suggested fix: Consider adding explicit print media styles or ensuring that all layout elements are properly sized for A4 printing. *Scanner: code-review/logic | * **[medium] Incorrect CSS media query for print**
The CSS uses `@page { size: A4; margin: 0; }` which is correct for print media, but the HTML document doesn't specify any print-specific styling or media queries. This could lead to inconsistent rendering when printing.
Suggested fix: Consider adding explicit print media styles or ensuring that all layout elements are properly sized for A4 printing.
*Scanner: code-review/logic | *
<!-- compliance-fp:2413b921b63684d0f5ccba2061b3801b5027ab5e3040451f81ef50942740f590 -->
|
||||
body {
|
||||
font-family: 'Plus Jakarta Sans', -apple-system, sans-serif;
|
||||
background: #fff;
|
||||
color: #1a1a2e;
|
||||
width: 210mm;
|
||||
height: 297mm;
|
||||
overflow: hidden;
|
||||
position: relative;
|
||||
|
sharang
commented
[medium] Potential overflow issue in fixed dimensions The body has fixed dimensions of 210mm x 297mm, but some content like lists and grids might exceed these boundaries without proper overflow handling, potentially causing visual clipping or layout issues. Suggested fix: Add overflow handling to key containers or use responsive units where appropriate to prevent content overflow. *Scanner: code-review/logic | * **[medium] Potential overflow issue in fixed dimensions**
The body has fixed dimensions of 210mm x 297mm, but some content like lists and grids might exceed these boundaries without proper overflow handling, potentially causing visual clipping or layout issues.
Suggested fix: Add overflow handling to key containers or use responsive units where appropriate to prevent content overflow.
*Scanner: code-review/logic | *
<!-- compliance-fp:27e404b399f91f2f39aec677e5823db8027d794c521adc8810bd98f486760fd0 -->
|
||||
}
|
||||
|
||||
.top-bar {
|
||||
height: 6px;
|
||||
background: linear-gradient(90deg, #6366f1, #8b5cf6, #a78bfa, #06b6d4);
|
||||
}
|
||||
|
||||
.container { padding: 16px 34px 10px; }
|
||||
|
||||
.header {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: flex-start;
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
.logo-area h1 {
|
||||
font-size: 26px;
|
||||
font-weight: 800;
|
||||
letter-spacing: -1px;
|
||||
color: #4f46e5;
|
||||
}
|
||||
.logo-area .tagline {
|
||||
font-size: 11px;
|
||||
color: #64748b;
|
||||
margin-top: 1px;
|
||||
}
|
||||
.contact-info {
|
||||
text-align: right;
|
||||
font-size: 9px;
|
||||
color: #94a3b8;
|
||||
line-height: 1.5;
|
||||
}
|
||||
|
||||
.hero {
|
||||
background: linear-gradient(135deg, #eef2ff, #f0f9ff);
|
||||
border-radius: 10px;
|
||||
padding: 10px 16px;
|
||||
margin-bottom: 10px;
|
||||
border-left: 4px solid #6366f1;
|
||||
}
|
||||
.hero p {
|
||||
font-size: 11px;
|
||||
line-height: 1.4;
|
||||
color: #334155;
|
||||
}
|
||||
.hero strong { color: #4f46e5; font-weight: 700; }
|
||||
|
||||
.columns {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 12px;
|
||||
margin-bottom: 9px;
|
||||
}
|
||||
|
||||
.product-card {
|
||||
border: 1px solid #e2e8f0;
|
||||
border-radius: 10px;
|
||||
padding: 10px 13px;
|
||||
position: relative;
|
||||
overflow: hidden;
|
||||
}
|
||||
.product-card::before {
|
||||
content: '';
|
||||
position: absolute;
|
||||
top: 0; left: 0; right: 0;
|
||||
height: 3px;
|
||||
}
|
||||
.product-card.scanner::before { background: linear-gradient(90deg, #6366f1, #8b5cf6); }
|
||||
.product-card.platform::before { background: linear-gradient(90deg, #06b6d4, #0ea5e9); }
|
||||
.product-card h2 {
|
||||
font-size: 13px;
|
||||
font-weight: 800;
|
||||
margin-bottom: 1px;
|
||||
}
|
||||
.product-card.scanner h2 { color: #4f46e5; }
|
||||
.product-card.platform h2 { color: #0891b2; }
|
||||
.product-card .subtitle {
|
||||
font-size: 9px;
|
||||
color: #94a3b8;
|
||||
margin-bottom: 6px;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.5px;
|
||||
}
|
||||
.product-card ul { list-style: none; padding: 0; }
|
||||
.product-card li {
|
||||
font-size: 9.5px;
|
||||
line-height: 1.25;
|
||||
padding: 1.8px 0;
|
||||
padding-left: 13px;
|
||||
position: relative;
|
||||
color: #475569;
|
||||
}
|
||||
.product-card li::before {
|
||||
content: '';
|
||||
position: absolute;
|
||||
left: 0;
|
||||
top: 6.5px;
|
||||
width: 5px;
|
||||
height: 5px;
|
||||
border-radius: 50%;
|
||||
}
|
||||
.product-card.scanner li::before { background: #818cf8; }
|
||||
.product-card.platform li::before { background: #22d3ee; }
|
||||
|
||||
.metrics {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(5, 1fr);
|
||||
gap: 8px;
|
||||
margin-bottom: 9px;
|
||||
}
|
||||
.metric {
|
||||
text-align: center;
|
||||
padding: 8px 4px;
|
||||
border-radius: 8px;
|
||||
background: #f8fafc;
|
||||
border: 1px solid #e2e8f0;
|
||||
}
|
||||
.metric .number {
|
||||
font-size: 17px;
|
||||
font-weight: 800;
|
||||
color: #4f46e5;
|
||||
}
|
||||
.metric .label {
|
||||
font-size: 8px;
|
||||
color: #64748b;
|
||||
margin-top: 1px;
|
||||
font-weight: 500;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.3px;
|
||||
}
|
||||
|
||||
.diff-section { margin-bottom: 9px; }
|
||||
.section-title {
|
||||
font-size: 10.5px;
|
||||
font-weight: 700;
|
||||
color: #1e293b;
|
||||
margin-bottom: 5px;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.5px;
|
||||
}
|
||||
.diff-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(3, 1fr);
|
||||
gap: 6px;
|
||||
}
|
||||
.diff-item {
|
||||
padding: 7px 9px;
|
||||
border-radius: 7px;
|
||||
background: linear-gradient(135deg, #faf5ff, #f0f9ff);
|
||||
border: 1px solid #e0e7ff;
|
||||
}
|
||||
.diff-item .diff-title {
|
||||
font-size: 9px;
|
||||
font-weight: 700;
|
||||
color: #4f46e5;
|
||||
margin-bottom: 1px;
|
||||
}
|
||||
.diff-item .diff-desc {
|
||||
font-size: 8px;
|
||||
color: #64748b;
|
||||
line-height: 1.25;
|
||||
}
|
||||
|
||||
.roadmap { margin-bottom: 9px; }
|
||||
.roadmap-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(4, 1fr);
|
||||
gap: 6px;
|
||||
}
|
||||
.roadmap-item {
|
||||
padding: 6px 9px;
|
||||
border-radius: 7px;
|
||||
border: 1px dashed #c7d2fe;
|
||||
background: #fefce8;
|
||||
}
|
||||
.roadmap-item .rm-title {
|
||||
font-size: 9px;
|
||||
font-weight: 700;
|
||||
color: #92400e;
|
||||
margin-bottom: 1px;
|
||||
}
|
||||
.roadmap-item .rm-desc {
|
||||
font-size: 7.5px;
|
||||
color: #78716c;
|
||||
line-height: 1.25;
|
||||
}
|
||||
|
||||
.bottom-row {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 12px;
|
||||
margin-bottom: 6px;
|
||||
}
|
||||
.bottom-section .section-title { margin-bottom: 4px; }
|
||||
.bottom-section ul { list-style: none; padding: 0; }
|
||||
.bottom-section li {
|
||||
font-size: 9px;
|
||||
color: #475569;
|
||||
padding: 1.5px 0;
|
||||
padding-left: 11px;
|
||||
position: relative;
|
||||
line-height: 1.3;
|
||||
}
|
||||
.bottom-section li::before {
|
||||
content: '→';
|
||||
position: absolute;
|
||||
left: 0;
|
||||
color: #8b5cf6;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.footer {
|
||||
position: absolute;
|
||||
bottom: 0;
|
||||
left: 0;
|
||||
right: 0;
|
||||
padding: 9px 34px;
|
||||
background: #f8fafc;
|
||||
border-top: 1px solid #e2e8f0;
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: center;
|
||||
}
|
||||
.footer .conf {
|
||||
font-size: 8px;
|
||||
color: #94a3b8;
|
||||
font-weight: 500;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.5px;
|
||||
}
|
||||
.footer .date {
|
||||
font-size: 8px;
|
||||
color: #94a3b8;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="top-bar"></div>
|
||||
<div class="container">
|
||||
|
||||
<div class="header">
|
||||
<div class="logo-area">
|
||||
<h1>CERTifAI</h1>
|
||||
<div class="tagline">KI-native Sicherheits- & Compliance-Plattform</div>
|
||||
</div>
|
||||
<div class="contact-info">
|
||||
Vertraulich — Nur für Investoren<br>
|
||||
März 2026
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="hero">
|
||||
<p>
|
||||
CERTifAI ist eine <strong>DSGVO-konforme, datensouveräne KI-Plattform</strong>, die autonomes
|
||||
Sicherheitsscanning mit intelligenter Compliance-Automatisierung vereint. Wir helfen Unternehmen,
|
||||
ihren <strong>Code abzusichern</strong>, <strong>Compliance skalierbar durchzusetzen</strong> und
|
||||
<strong>volle Datensouveränität zu bewahren</strong> — gestützt auf über 200 atomare Sicherheitskontrollen,
|
||||
KI-gesteuerte Triage und einen lückenlosen Audit-Trail für jeden Befund.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="columns">
|
||||
<div class="product-card scanner">
|
||||
<h2>Compliance Scanner</h2>
|
||||
<div class="subtitle">Autonomer KI-Sicherheitsagent</div>
|
||||
<ul>
|
||||
<li><strong>200+ atomare Kontrollen</strong> — Feingranulare Sicherheitsprüfungen mit vollständiger Herkunftsverfolgung</li>
|
||||
<li><strong>SAST + DAST + SBOM</strong> — Vollumfängliche Sicherheitstests mit Schwachstellenverfolgung</li>
|
||||
<li><strong>KI-gesteuerte Pentests</strong> — Autonome, LLM-orchestrierte Penetrationstests mit verschlüsselten Berichten</li>
|
||||
<li><strong>Automatische PR-Reviews</strong> — Sicherheitsbewusste Code-Review-Kommentare bei jedem Pull Request</li>
|
||||
<li><strong>Audit-Trail</strong> — Unveränderliche Befund-Nachverfolgung von Erkennung bis Behebung</li>
|
||||
<li><strong>LLM-basierte Triage</strong> — Intelligente False-Positive-Filterung mit Konfidenz-Scoring</li>
|
||||
<li><strong>Code-Wissensgraph</strong> — Architekturvisualisierung mit Auswirkungs- & Datenflussanalyse</li>
|
||||
<li><strong>Multi-Tracker-Sync</strong> — Automatische Issues in GitHub, GitLab, Jira, Gitea</li>
|
||||
<li><strong>MCP-Server</strong> — Live-Sicherheitsdaten in Claude, Cursor & anderen KI-Tools</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="product-card platform">
|
||||
<h2>CERTifAI Plattform</h2>
|
||||
<div class="subtitle">Souveräne GenAI-Infrastruktur</div>
|
||||
<ul>
|
||||
<li><strong>Multi-Provider LLM-Verwaltung</strong> — Einheitliche Schnittstelle für LiteLLM, OpenAI, HuggingFace, Anthropic</li>
|
||||
<li><strong>KI-Agenten-Orchestrierung</strong> — LangGraph-Integration mit Live-Monitoring & Agenten-Registry</li>
|
||||
<li><strong>Enterprise SSO</strong> — Keycloak-basiertes OAuth2/PKCE, LDAP, Multi-Realm-Authentifizierung</li>
|
||||
<li><strong>Nutzungs- & Abrechnungsanalyse</strong> — Token-Tracking, modellbasierte Aufschlüsselung</li>
|
||||
<li><strong>News-Intelligence</strong> — KI-gestützte Nachrichtenzusammenfassung, Trendanalyse, Follow-up-Chat</li>
|
||||
<li><strong>Entwickler-Toolchain</strong> — LangFlow, Langfuse, LangChain sofort einsatzbereit</li>
|
||||
<li><strong>RBAC & Feature Flags</strong> — Rollenbasierter Zugriff mit kontrolliertem GenAI-Rollout pro Org</li>
|
||||
<li><strong>Mehrsprachigkeit</strong> — Vollständige i18n-Unterstützung (DE, FR, ES, PT)</li>
|
||||
<li><strong>RAG-basierter Chat</strong> — Natürlichsprachliche Q&A auf Basis Ihrer Codebasis</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="metrics">
|
||||
<div class="metric">
|
||||
<div class="number">15 Mrd.+</div>
|
||||
<div class="label">AppSec TAM bis 2027</div>
|
||||
</div>
|
||||
<div class="metric">
|
||||
<div class="number">200+</div>
|
||||
<div class="label">Atomare Sicherheits-<br>kontrollen</div>
|
||||
</div>
|
||||
<div class="metric">
|
||||
<div class="number">80%</div>
|
||||
<div class="label">Zeitersparnis bei<br>Compliance-Prüfungen</div>
|
||||
</div>
|
||||
<div class="metric">
|
||||
<div class="number">10x</div>
|
||||
<div class="label">Günstiger als<br>manuelle Pentests</div>
|
||||
</div>
|
||||
<div class="metric">
|
||||
<div class="number">100%</div>
|
||||
<div class="label">Datensouveränität<br>garantiert</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="diff-section">
|
||||
<div class="section-title">Warum CERTifAI gewinnt</div>
|
||||
<div class="diff-grid">
|
||||
<div class="diff-item">
|
||||
<div class="diff-title">KI-native Sicherheit</div>
|
||||
<div class="diff-desc">LLM-gesteuerte Pentests & Triage ersetzen manuelle Audits (5.000–50.000 €). Kein Wettbewerber bietet autonome KI-Pentests.</div>
|
||||
</div>
|
||||
<div class="diff-item">
|
||||
<div class="diff-title">Volle Provenienz</div>
|
||||
<div class="diff-desc">Jeder Befund rückverfolgbar zu Kontrolle, Regel und Quelle. Lückenloser Audit-Trail von Erkennung bis Behebung.</div>
|
||||
</div>
|
||||
<div class="diff-item">
|
||||
<div class="diff-title">Datensouveränität</div>
|
||||
<div class="diff-desc">Keine Daten verlassen Ihre Infrastruktur. DSGVO-konform durch Architektur. EU-Hosting-Optionen verfügbar.</div>
|
||||
</div>
|
||||
<div class="diff-item">
|
||||
<div class="diff-title">Shift-Left PR-Reviews</div>
|
||||
<div class="diff-desc">Sicherheitsbefunde erscheinen als PR-Kommentare vor dem Merge. Entwickler beheben Probleme direkt am Code.</div>
|
||||
</div>
|
||||
<div class="diff-item">
|
||||
<div class="diff-title">Entwickelt in Rust</div>
|
||||
<div class="diff-desc">Speichersicherer, hochperformanter Stack. Fullstack-WASM + SSR mit Dioxus. Enterprise-taugliche Zuverlässigkeit.</div>
|
||||
</div>
|
||||
<div class="diff-item">
|
||||
<div class="diff-title">Einheitliche Steuerung</div>
|
||||
<div class="diff-desc">Sicherheit + KI-Infrastruktur in einem Dashboard. Wettbewerber benötigen 5+ separate Tools.</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="roadmap">
|
||||
<div class="section-title">Roadmap — In Kürze verfügbar</div>
|
||||
<div class="roadmap-grid">
|
||||
<div class="roadmap-item">
|
||||
<div class="rm-title">SOC2 & ISO 27001</div>
|
||||
<div class="rm-desc">Vorgefertigte Kontroll-Mappings für Zertifizierungsreife</div>
|
||||
</div>
|
||||
<div class="roadmap-item">
|
||||
<div class="rm-title">Policy-as-Code</div>
|
||||
<div class="rm-desc">Eigene Compliance-Regeln via deklarative YAML-Policies</div>
|
||||
</div>
|
||||
<div class="roadmap-item">
|
||||
<div class="rm-title">CI/CD-Gates</div>
|
||||
<div class="rm-desc">Deployments bei kritischen Befunden blockieren</div>
|
||||
</div>
|
||||
<div class="roadmap-item">
|
||||
<div class="rm-title">Executive Reports</div>
|
||||
<div class="rm-desc">Auto-generierte Compliance-Berichte für die Geschäftsführung</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="bottom-row">
|
||||
<div class="bottom-section">
|
||||
<div class="section-title">Geschäftsmodell</div>
|
||||
<ul>
|
||||
<li><strong>SaaS Cloud</strong> — Verwaltete Multi-Tenant-Plattform für KMUs</li>
|
||||
<li><strong>Enterprise-Lizenz</strong> — Dedizierte Bereitstellung mit Support & Integrationen</li>
|
||||
<li><strong>Professional Services</strong> — Individuelle Regeln, Pentest-Berichte, Compliance-Audits</li>
|
||||
<li><strong>API-Stufen</strong> — Kostenlose Community-Stufe, kostenpflichtiger Enterprise-Zugang</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="bottom-section">
|
||||
<div class="section-title">Zielmärkte</div>
|
||||
<ul>
|
||||
<li><strong>Regulierte Branchen</strong> — Finanzen, Gesundheitswesen, Behörden (DSGVO, HIPAA, SOC2)</li>
|
||||
<li><strong>Enterprise DevSecOps</strong> — Shift-Left-Security für Entwicklungsteams</li>
|
||||
<li><strong>EU-Datensouveränität</strong> — Unternehmen mit souveräner KI-Infrastruktur</li>
|
||||
<li><strong>Sicherheitsberatungen</strong> — Automatisierte Pentests & Berichtserstellung</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
sharang
commented
[low] Hardcoded date in footer The footer contains a hardcoded date 'März 2026' which will become outdated quickly. While this may be intentional for a static document, it's worth noting as a potential maintenance issue. Suggested fix: Consider making the date dynamic if this document is intended to be updated regularly, or add a comment indicating this is intentionally static. *Scanner: code-review/logic | * **[low] Hardcoded date in footer**
The footer contains a hardcoded date 'März 2026' which will become outdated quickly. While this may be intentional for a static document, it's worth noting as a potential maintenance issue.
Suggested fix: Consider making the date dynamic if this document is intended to be updated regularly, or add a comment indicating this is intentionally static.
*Scanner: code-review/logic | *
<!-- compliance-fp:2a67c0c8af5d246005bc4c0d77e6cab170765c5f6a7f017401eabd1d2d5d8157 -->
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="footer">
|
||||
<div class="conf">Vertraulich — Nicht zur Weitergabe bestimmt</div>
|
||||
<div class="date">CERTifAI — März 2026</div>
|
||||
</div>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
421
onepager_en.html
Normal file
@@ -0,0 +1,421 @@
|
||||
<!DOCTYPE html>
|
||||
|
sharang
commented
[medium] Potential Information Disclosure Through HTML Metadata The HTML document contains confidential metadata in the form of a 'Confidential — For Investor Review' header and footer, along with a date 'March 2026'. While this is not directly exploitable, it could be used in social engineering attacks or indicate internal information leakage if the document were to be improperly shared. Suggested fix: Remove or obfuscate any sensitive metadata that could aid in social engineering or information gathering efforts. Scanner: code-review/security | CWE: CWE-200 **[medium] Potential Information Disclosure Through HTML Metadata**
The HTML document contains confidential metadata in the form of a 'Confidential — For Investor Review' header and footer, along with a date 'March 2026'. While this is not directly exploitable, it could be used in social engineering attacks or indicate internal information leakage if the document were to be improperly shared.
Suggested fix: Remove or obfuscate any sensitive metadata that could aid in social engineering or information gathering efforts.
*Scanner: code-review/security | CWE: CWE-200*
<!-- compliance-fp:93294af407cf082a99c774f0569f78f6d9f2c10cae8c719b1dd2b13668278b6e -->
sharang
commented
[medium] Excessive HTML Structure Complexity The HTML structure contains deeply nested elements with multiple semantic layers that make it difficult to maintain and understand. The document has complex nested sections with repetitive patterns that could benefit from a more modular approach. Suggested fix: Consider breaking down the large HTML structure into smaller components or using a templating system to reduce nesting depth and improve maintainability. *Scanner: code-review/complexity | * **[medium] Excessive HTML Structure Complexity**
The HTML structure contains deeply nested elements with multiple semantic layers that make it difficult to maintain and understand. The document has complex nested sections with repetitive patterns that could benefit from a more modular approach.
Suggested fix: Consider breaking down the large HTML structure into smaller components or using a templating system to reduce nesting depth and improve maintainability.
*Scanner: code-review/complexity | *
<!-- compliance-fp:29375e46d13e9f7f7da6f82263fe55add4db07c422c475480ea337bbd575cd78 -->
sharang
commented
[medium] Missing type annotations in HTML template The HTML file contains embedded CSS and JavaScript but lacks proper type annotations for any JavaScript functions or variables that might be present. This could lead to runtime issues if JavaScript is added later without proper typing. Suggested fix: Add type annotations to any JavaScript code if present, or ensure that any dynamic content is properly typed in the surrounding context. *Scanner: code-review/convention | * **[medium] Missing type annotations in HTML template**
The HTML file contains embedded CSS and JavaScript but lacks proper type annotations for any JavaScript functions or variables that might be present. This could lead to runtime issues if JavaScript is added later without proper typing.
Suggested fix: Add type annotations to any JavaScript code if present, or ensure that any dynamic content is properly typed in the surrounding context.
*Scanner: code-review/convention | *
<!-- compliance-fp:d179b8e012b246f39b6819fa987ded54eb78e16f1c7defb24d7072a5818ab1ef -->
sharang
commented
[low] Missing alt attributes on images While there are no explicit image tags in this HTML, if any images were added later they would lack alt attributes which are essential for accessibility and SEO. Suggested fix: Add descriptive alt attributes to all images when present. *Scanner: code-review/logic | * **[low] Missing alt attributes on images**
While there are no explicit image tags in this HTML, if any images were added later they would lack alt attributes which are essential for accessibility and SEO.
Suggested fix: Add descriptive alt attributes to all images when present.
*Scanner: code-review/logic | *
<!-- compliance-fp:b46dce90323db0ff6c9e518d34e0e89e1c278123e4482309c89ffa98bf06b3aa -->
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>CERTifAI — Investor One-Pager</title>
|
||||
<link href="https://fonts.googleapis.com/css2?family=Plus+Jakarta+Sans:wght@300;400;500;600;700;800&display=swap" rel="stylesheet">
|
||||
<style>
|
||||
@page { size: A4; margin: 0; }
|
||||
* { margin: 0; padding: 0; box-sizing: border-box; }
|
||||
body {
|
||||
font-family: 'Plus Jakarta Sans', -apple-system, sans-serif;
|
||||
|
sharang
commented
[medium] Large CSS Stylesheet The CSS stylesheet spans 300+ lines and contains numerous style definitions that could be better organized into logical groups or separated into external files for better maintainability. Suggested fix: Break the CSS into logical sections (layout, typography, components) and consider moving to an external stylesheet to improve organization and readability. *Scanner: code-review/complexity | * **[medium] Large CSS Stylesheet**
The CSS stylesheet spans 300+ lines and contains numerous style definitions that could be better organized into logical groups or separated into external files for better maintainability.
Suggested fix: Break the CSS into logical sections (layout, typography, components) and consider moving to an external stylesheet to improve organization and readability.
*Scanner: code-review/complexity | *
<!-- compliance-fp:b441061145279d74029110b594a0bf8cd028623211868b3b75a3a92d1996d211 -->
sharang
commented
[medium] Incorrect CSS media query for print The CSS uses Suggested fix: Consider removing the fixed width/height from body and relying solely on @page for proper A4 sizing during print. *Scanner: code-review/logic | * **[medium] Incorrect CSS media query for print**
The CSS uses `@page { size: A4; margin: 0; }` which is correct for print styling, but the body has fixed dimensions (`width: 210mm; height: 297mm`) that may conflict with actual page rendering. This could cause layout issues when printing or converting to PDF.
Suggested fix: Consider removing the fixed width/height from body and relying solely on @page for proper A4 sizing during print.
*Scanner: code-review/logic | *
<!-- compliance-fp:dc7a9ba3f796e219252634608f9185e6fabbe03dc7f93df1c760783f55d27512 -->
|
||||
background: #fff;
|
||||
color: #1a1a2e;
|
||||
width: 210mm;
|
||||
height: 297mm;
|
||||
overflow: hidden;
|
||||
position: relative;
|
||||
}
|
||||
|
||||
.top-bar {
|
||||
height: 6px;
|
||||
background: linear-gradient(90deg, #6366f1, #8b5cf6, #a78bfa, #06b6d4);
|
||||
}
|
||||
|
||||
.container { padding: 18px 34px 12px; }
|
||||
|
||||
.header {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
|
sharang
commented
[medium] Hardcoded Date in Document The document includes a hardcoded date 'March 2026' which may expose internal planning timelines or project schedules. This could potentially be leveraged by attackers for strategic purposes. Suggested fix: Consider making the date dynamic or removing it entirely to prevent exposure of internal scheduling information. Scanner: code-review/security | CWE: CWE-200 **[medium] Hardcoded Date in Document**
The document includes a hardcoded date 'March 2026' which may expose internal planning timelines or project schedules. This could potentially be leveraged by attackers for strategic purposes.
Suggested fix: Consider making the date dynamic or removing it entirely to prevent exposure of internal scheduling information.
*Scanner: code-review/security | CWE: CWE-200*
<!-- compliance-fp:2c7f7bcdf399dc59310fddd58e40028b70035c4c8270dbade53c78bd70f39698 -->
|
||||
align-items: flex-start;
|
||||
margin-bottom: 12px;
|
||||
}
|
||||
.logo-area h1 {
|
||||
font-size: 28px;
|
||||
font-weight: 800;
|
||||
letter-spacing: -1px;
|
||||
color: #4f46e5;
|
||||
}
|
||||
.logo-area .tagline {
|
||||
font-size: 12px;
|
||||
color: #64748b;
|
||||
margin-top: 1px;
|
||||
}
|
||||
.contact-info {
|
||||
text-align: right;
|
||||
font-size: 9.5px;
|
||||
color: #94a3b8;
|
||||
line-height: 1.5;
|
||||
}
|
||||
|
||||
.hero {
|
||||
background: linear-gradient(135deg, #eef2ff, #f0f9ff);
|
||||
border-radius: 10px;
|
||||
padding: 11px 18px;
|
||||
margin-bottom: 11px;
|
||||
border-left: 4px solid #6366f1;
|
||||
}
|
||||
.hero p {
|
||||
font-size: 11.5px;
|
||||
line-height: 1.45;
|
||||
color: #334155;
|
||||
}
|
||||
.hero strong { color: #4f46e5; font-weight: 700; }
|
||||
|
||||
.columns {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 14px;
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
|
||||
.product-card {
|
||||
border: 1px solid #e2e8f0;
|
||||
border-radius: 10px;
|
||||
padding: 12px 14px;
|
||||
position: relative;
|
||||
overflow: hidden;
|
||||
}
|
||||
.product-card::before {
|
||||
content: '';
|
||||
position: absolute;
|
||||
top: 0; left: 0; right: 0;
|
||||
height: 3px;
|
||||
}
|
||||
.product-card.scanner::before { background: linear-gradient(90deg, #6366f1, #8b5cf6); }
|
||||
.product-card.platform::before { background: linear-gradient(90deg, #06b6d4, #0ea5e9); }
|
||||
.product-card h2 {
|
||||
font-size: 13.5px;
|
||||
font-weight: 800;
|
||||
margin-bottom: 2px;
|
||||
}
|
||||
.product-card.scanner h2 { color: #4f46e5; }
|
||||
.product-card.platform h2 { color: #0891b2; }
|
||||
.product-card .subtitle {
|
||||
font-size: 9.5px;
|
||||
color: #94a3b8;
|
||||
margin-bottom: 7px;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.5px;
|
||||
}
|
||||
.product-card ul { list-style: none; padding: 0; }
|
||||
.product-card li {
|
||||
font-size: 10px;
|
||||
line-height: 1.3;
|
||||
padding: 2px 0;
|
||||
padding-left: 14px;
|
||||
position: relative;
|
||||
color: #475569;
|
||||
}
|
||||
.product-card li::before {
|
||||
content: '';
|
||||
position: absolute;
|
||||
left: 0;
|
||||
top: 7px;
|
||||
width: 5px;
|
||||
height: 5px;
|
||||
border-radius: 50%;
|
||||
}
|
||||
|
sharang
commented
[medium] Potential layout inconsistency in metrics section The metrics section uses Suggested fix: Avoid using *Scanner: code-review/logic | * **[medium] Potential layout inconsistency in metrics section**
The metrics section uses `grid-template-columns: repeat(5, 1fr)` but some metric labels contain line breaks (`<br>`). This can cause inconsistent column widths and visual misalignment when rendered in different browsers or environments.
Suggested fix: Avoid using `<br>` tags inside labels or ensure consistent use across all metrics to maintain grid alignment.
*Scanner: code-review/logic | *
<!-- compliance-fp:4d47d5cc5846645b7a0f8f30befd7f6ee8c85dcdfe703e37041549f1dd8d5259 -->
|
||||
.product-card.scanner li::before { background: #818cf8; }
|
||||
.product-card.platform li::before { background: #22d3ee; }
|
||||
|
||||
.metrics {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(5, 1fr);
|
||||
gap: 9px;
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
.metric {
|
||||
text-align: center;
|
||||
padding: 9px 5px;
|
||||
border-radius: 8px;
|
||||
background: #f8fafc;
|
||||
border: 1px solid #e2e8f0;
|
||||
}
|
||||
.metric .number {
|
||||
font-size: 18px;
|
||||
font-weight: 800;
|
||||
color: #4f46e5;
|
||||
}
|
||||
.metric .label {
|
||||
font-size: 8.5px;
|
||||
color: #64748b;
|
||||
margin-top: 1px;
|
||||
font-weight: 500;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.3px;
|
||||
}
|
||||
|
||||
.diff-section { margin-bottom: 10px; }
|
||||
.section-title {
|
||||
font-size: 11px;
|
||||
font-weight: 700;
|
||||
color: #1e293b;
|
||||
margin-bottom: 6px;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.5px;
|
||||
}
|
||||
.diff-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(3, 1fr);
|
||||
gap: 7px;
|
||||
}
|
||||
.diff-item {
|
||||
padding: 8px 10px;
|
||||
border-radius: 7px;
|
||||
background: linear-gradient(135deg, #faf5ff, #f0f9ff);
|
||||
border: 1px solid #e0e7ff;
|
||||
}
|
||||
.diff-item .diff-title {
|
||||
font-size: 9.5px;
|
||||
font-weight: 700;
|
||||
color: #4f46e5;
|
||||
margin-bottom: 2px;
|
||||
}
|
||||
.diff-item .diff-desc {
|
||||
font-size: 8.5px;
|
||||
color: #64748b;
|
||||
line-height: 1.3;
|
||||
}
|
||||
|
||||
/* Roadmap */
|
||||
.roadmap {
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
.roadmap-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(4, 1fr);
|
||||
gap: 7px;
|
||||
}
|
||||
.roadmap-item {
|
||||
padding: 7px 10px;
|
||||
border-radius: 7px;
|
||||
border: 1px dashed #c7d2fe;
|
||||
background: #fefce8;
|
||||
}
|
||||
.roadmap-item .rm-title {
|
||||
font-size: 9.5px;
|
||||
font-weight: 700;
|
||||
color: #92400e;
|
||||
margin-bottom: 1px;
|
||||
}
|
||||
.roadmap-item .rm-desc {
|
||||
font-size: 8px;
|
||||
color: #78716c;
|
||||
line-height: 1.3;
|
||||
}
|
||||
|
||||
.bottom-row {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 14px;
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
.bottom-section .section-title { margin-bottom: 5px; }
|
||||
.bottom-section ul { list-style: none; padding: 0; }
|
||||
.bottom-section li {
|
||||
font-size: 9.5px;
|
||||
color: #475569;
|
||||
padding: 2px 0;
|
||||
padding-left: 12px;
|
||||
position: relative;
|
||||
line-height: 1.35;
|
||||
}
|
||||
.bottom-section li::before {
|
||||
content: '→';
|
||||
position: absolute;
|
||||
left: 0;
|
||||
color: #8b5cf6;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.footer {
|
||||
position: absolute;
|
||||
bottom: 0;
|
||||
left: 0;
|
||||
right: 0;
|
||||
padding: 10px 34px;
|
||||
background: #f8fafc;
|
||||
border-top: 1px solid #e2e8f0;
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: center;
|
||||
}
|
||||
.footer .conf {
|
||||
font-size: 8.5px;
|
||||
color: #94a3b8;
|
||||
font-weight: 500;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.5px;
|
||||
}
|
||||
.footer .date {
|
||||
font-size: 8.5px;
|
||||
color: #94a3b8;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="top-bar"></div>
|
||||
<div class="container">
|
||||
|
||||
<div class="header">
|
||||
<div class="logo-area">
|
||||
<h1>CERTifAI</h1>
|
||||
<div class="tagline">AI-Native Security & Compliance Platform</div>
|
||||
</div>
|
||||
<div class="contact-info">
|
||||
Confidential — For Investor Review<br>
|
||||
March 2026
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="hero">
|
||||
<p>
|
||||
CERTifAI is a <strong>GDPR-compliant, data-sovereign AI platform</strong> combining autonomous security scanning
|
||||
with intelligent compliance automation. We help enterprises <strong>secure their code</strong>,
|
||||
<strong>enforce compliance at scale</strong>, and <strong>maintain full data sovereignty</strong> — powered by
|
||||
200+ atomic security controls, AI-driven triage, and a complete audit trail for every finding.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="columns">
|
||||
<div class="product-card scanner">
|
||||
<h2>Compliance Scanner</h2>
|
||||
<div class="subtitle">Autonomous AI Security Agent</div>
|
||||
<ul>
|
||||
<li><strong>200+ Atomic Controls</strong> — Fine-grained security checks with full provenance tracking per finding</li>
|
||||
<li><strong>SAST + DAST + SBOM</strong> — Full-spectrum security testing with dependency vulnerability tracking</li>
|
||||
<li><strong>AI-Driven Pentesting</strong> — Autonomous LLM-orchestrated penetration testing with encrypted reports</li>
|
||||
<li><strong>Automated PR Reviews</strong> — Security-aware code review comments on every pull request</li>
|
||||
<li><strong>Audit Trail</strong> — Immutable finding lifecycle tracking from detection to remediation</li>
|
||||
<li><strong>LLM-Powered Triage</strong> — Intelligent false-positive filtering with confidence scoring</li>
|
||||
<li><strong>Code Knowledge Graph</strong> — Architecture visualization with impact & data-flow analysis</li>
|
||||
<li><strong>Multi-Tracker Sync</strong> — Auto-creates issues in GitHub, GitLab, Jira, Gitea</li>
|
||||
<li><strong>MCP Server</strong> — Live security data in Claude, Cursor & other AI dev tools</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="product-card platform">
|
||||
<h2>CERTifAI Platform</h2>
|
||||
<div class="subtitle">Sovereign GenAI Infrastructure</div>
|
||||
<ul>
|
||||
<li><strong>Multi-Provider LLM Management</strong> — Unified interface for LiteLLM, OpenAI, HuggingFace, Anthropic</li>
|
||||
<li><strong>AI Agent Orchestration</strong> — LangGraph integration with live monitoring & agent registry</li>
|
||||
<li><strong>Enterprise SSO</strong> — Keycloak-based OAuth2/PKCE, LDAP, multi-realm authentication</li>
|
||||
<li><strong>Usage & Billing Analytics</strong> — Token tracking, per-model breakdown, seat management</li>
|
||||
<li><strong>News Intelligence</strong> — AI-powered news summarization, trend analysis, follow-up chat</li>
|
||||
<li><strong>Developer Toolchain</strong> — LangFlow, Langfuse, LangChain integrations out of the box</li>
|
||||
<li><strong>RBAC & Feature Flags</strong> — Role-based access with controlled GenAI rollout per org</li>
|
||||
<li><strong>Full i18n</strong> — Multi-language support (DE, FR, ES, PT) for global teams</li>
|
||||
<li><strong>RAG-Powered Chat</strong> — Natural language Q&A grounded in your codebase</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="metrics">
|
||||
<div class="metric">
|
||||
<div class="number">$15B+</div>
|
||||
<div class="label">AppSec TAM by 2027</div>
|
||||
</div>
|
||||
<div class="metric">
|
||||
<div class="number">200+</div>
|
||||
<div class="label">Atomic Security<br>Controls</div>
|
||||
</div>
|
||||
<div class="metric">
|
||||
<div class="number">80%</div>
|
||||
<div class="label">Compliance Review<br>Time Saved</div>
|
||||
</div>
|
||||
<div class="metric">
|
||||
<div class="number">10x</div>
|
||||
<div class="label">Cheaper than<br>Manual Pentests</div>
|
||||
</div>
|
||||
<div class="metric">
|
||||
<div class="number">100%</div>
|
||||
<div class="label">Data Sovereignty<br>Guaranteed</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="diff-section">
|
||||
<div class="section-title">Why CERTifAI Wins</div>
|
||||
<div class="diff-grid">
|
||||
<div class="diff-item">
|
||||
<div class="diff-title">AI-Native Security</div>
|
||||
<div class="diff-desc">LLM-driven pentesting & triage replace $5K–$50K manual engagements. No competitor offers autonomous AI pentests.</div>
|
||||
</div>
|
||||
<div class="diff-item">
|
||||
<div class="diff-title">Full Provenance</div>
|
||||
<div class="diff-desc">Every finding traces back to its control, rule, and source. Complete audit trail from detection through remediation.</div>
|
||||
</div>
|
||||
<div class="diff-item">
|
||||
<div class="diff-title">Data Sovereignty</div>
|
||||
<div class="diff-desc">Zero data leaves your infrastructure. GDPR-compliant by architecture. EU-hosted deployment options.</div>
|
||||
</div>
|
||||
<div class="diff-item">
|
||||
<div class="diff-title">Shift-Left PR Reviews</div>
|
||||
<div class="diff-desc">Security findings surface as PR comments before code merges. Developers fix issues at the source, not in production.</div>
|
||||
</div>
|
||||
<div class="diff-item">
|
||||
<div class="diff-title">Built in Rust</div>
|
||||
<div class="diff-desc">Memory-safe, high-performance stack. Fullstack WASM + SSR with Dioxus. Enterprise-grade reliability.</div>
|
||||
</div>
|
||||
<div class="diff-item">
|
||||
<div class="diff-title">Unified Control Plane</div>
|
||||
<div class="diff-desc">Security + AI infrastructure in one dashboard. Competitors require 5+ separate tools to match.</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="roadmap">
|
||||
<div class="section-title">Roadmap — Coming Soon</div>
|
||||
<div class="roadmap-grid">
|
||||
<div class="roadmap-item">
|
||||
<div class="rm-title">SOC2 & ISO 27001</div>
|
||||
<div class="rm-desc">Pre-built control mappings for certification readiness</div>
|
||||
</div>
|
||||
<div class="roadmap-item">
|
||||
<div class="rm-title">Policy-as-Code</div>
|
||||
<div class="rm-desc">Custom compliance rules via declarative YAML policies</div>
|
||||
</div>
|
||||
<div class="roadmap-item">
|
||||
<div class="rm-title">CI/CD Gates</div>
|
||||
<div class="rm-desc">Block deploys on critical findings with pipeline integration</div>
|
||||
</div>
|
||||
<div class="roadmap-item">
|
||||
<div class="rm-title">Executive Reports</div>
|
||||
<div class="rm-desc">Auto-generated compliance posture reports for leadership</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="bottom-row">
|
||||
<div class="bottom-section">
|
||||
<div class="section-title">Business Model</div>
|
||||
<ul>
|
||||
<li><strong>SaaS Cloud</strong> — Managed multi-tenant platform for SMBs</li>
|
||||
<li><strong>Enterprise License</strong> — Dedicated deployment with support & custom integrations</li>
|
||||
<li><strong>Professional Services</strong> — Custom rules, pentest reports, compliance audits</li>
|
||||
<li><strong>API Tiers</strong> — Free community tier, paid enterprise API access</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="bottom-section">
|
||||
<div class="section-title">Target Markets</div>
|
||||
<ul>
|
||||
<li><strong>Regulated Industries</strong> — Finance, healthcare, government (GDPR, HIPAA, SOC2)</li>
|
||||
<li><strong>Enterprise DevSecOps</strong> — Shift-left security for engineering teams</li>
|
||||
<li><strong>EU Data Sovereignty</strong> — Companies requiring sovereign AI infrastructure</li>
|
||||
<li><strong>Security Consultancies</strong> — Automated pentesting & report generation</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="footer">
|
||||
<div class="conf">Confidential — Do Not Distribute</div>
|
||||
<div class="date">CERTifAI — March 2026</div>
|
||||
</div>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
BIN
onepager_en_preview.png
Normal file
|
After Width: | Height: | Size: 253 KiB |
[low] Missing type annotations in function signatures
The function signatures in descriptions.rs and fixes.rs lack explicit return type annotations, which could make the code harder to understand and maintain. While Rust's type inference usually handles this, explicit annotations improve readability and prevent potential confusion.
Suggested fix: Add explicit return type annotations to function signatures for better clarity
*Scanner: code-review/convention | *