Microsoft Defender for IoT vulnerabilities{model.summaryRowCount.toLocaleString('en-US')} source asset rows{model.diagnostics.length.toLocaleString('en-US')} diagnostics
+ {/* Defender-CVEs aggregieren betroffene Devices; der affectedAsset
+ traegt die aggregierte Betroffenheit als Anzahl (Affected Device
+ Count), der eigentliche Geraetebeleg steht als Tabelle im
+ Ergebnisfenster. */}
+ {item.sourceProfileId === 'defender-for-iot-vulnerabilities'
+ ?
}
;
}
diff --git a/src/persistence/assessor-repository.ts b/src/persistence/assessor-repository.ts
index e5c7c07..9d0163f 100644
--- a/src/persistence/assessor-repository.ts
+++ b/src/persistence/assessor-repository.ts
@@ -31,6 +31,7 @@ import type {
UnifiedResultQueryResult
} from '../domain/unified-result';
import type { EnvironmentObservation, EnvironmentSnapshot, EnvironmentSnapshotQuery, ScannerReportSection } from '../domain/environment-context';
+import type { CveEnrichmentRecord } from '../domain/cve-enrichment';
export interface FindingOccurrenceQuery {
projectId?: string;
@@ -125,6 +126,7 @@ export interface ProjectDataExport {
environmentObservations: EnvironmentObservation[];
findingDefinitions: FindingDefinition[];
findingOccurrences: FindingOccurrence[];
+ cveEnrichments: CveEnrichmentRecord[];
evidence: EvidenceRecord[];
reviews: FindingReview[];
diagnostics: ImportDiagnostic[];
@@ -202,6 +204,9 @@ export interface AssessorRepository {
getUnifiedResultById(resultProjectionId: string): Promise;
listResultCategories(query?: UnifiedResultQuery): Promise;
getEnvironmentSnapshot(query: EnvironmentSnapshotQuery): Promise;
+ getCveEnrichment(cveId: string): Promise;
+ listCveEnrichments(cveIds: string[]): Promise;
+ saveCveEnrichment(record: CveEnrichmentRecord): Promise;
saveImportArtifact(artifact: ImportArtifact): Promise;
saveImportArtifactAndEnqueueJob(artifact: ImportArtifact, job: IngestionJob): Promise;
diff --git a/src/persistence/local-assessor-repository.ts b/src/persistence/local-assessor-repository.ts
index 5f076e8..558d513 100644
--- a/src/persistence/local-assessor-repository.ts
+++ b/src/persistence/local-assessor-repository.ts
@@ -24,6 +24,8 @@ import { storedPolicyEvaluationValidationErrors } from '../domain/policy-evaluat
import type { StoredPolicyFindingRun } from '../domain/policy-finding';
import type { EnvironmentObservation, EnvironmentSnapshot, EnvironmentSnapshotQuery, ScannerReportSection } from '../domain/environment-context';
import { environmentCoverage } from '../domain/environment-context';
+import type { CveEnrichmentRecord } from '../domain/cve-enrichment';
+import { cveEnrichmentValidationErrors, cveIdFromRuleId, normalizeCveId } from '../domain/cve-enrichment';
import { storedPolicyFindingRunValidationErrors } from '../domain/policy-finding';
import {
environmentProfileValidationErrors,
@@ -88,6 +90,7 @@ interface LocalRepositoryState {
environmentObservations: EnvironmentObservation[];
findingDefinitions: FindingDefinition[];
findingOccurrences: FindingOccurrence[];
+ cveEnrichments: CveEnrichmentRecord[];
evidence: EvidenceRecord[];
reviews: FindingReview[];
diagnostics: ImportDiagnostic[];
@@ -120,6 +123,7 @@ const emptyState = (): LocalRepositoryState => ({
environmentObservations: [],
findingDefinitions: [],
findingOccurrences: [],
+ cveEnrichments: [],
evidence: [],
reviews: [],
diagnostics: [],
@@ -181,6 +185,10 @@ function assessmentModel(state: LocalRepositoryState, assessmentId: string): Can
const findingOccurrences = state.findingOccurrences.filter(occurrence => runIds.has(occurrence.scanRunId));
const occurrenceIds = new Set(findingOccurrences.map(occurrence => occurrence.id));
const definitionIds = referencedDefinitionIds(state, occurrenceIds);
+ const cveIds = new Set(findingOccurrences.flatMap(occurrence => {
+ const id = cveIdFromRuleId(occurrence.sourceIdentity.canonicalRuleId ?? occurrence.sourceIdentity.originalRuleId);
+ return id ? [id] : [];
+ }));
state.reviews.forEach(review => {
if (review.target.kind === 'definition') {
const definitionId = review.target.definitionId;
@@ -200,6 +208,7 @@ function assessmentModel(state: LocalRepositoryState, assessmentId: string): Can
environmentObservations: byId(environmentObservations).map(clone),
findingDefinitions: byId(state.findingDefinitions.filter(definition => definitionIds.has(definition.id))).map(clone),
findingOccurrences: byId(findingOccurrences).map(clone),
+ cveEnrichments: state.cveEnrichments.filter(record => cveIds.has(record.cveId)).map(clone),
evidence: byId(state.evidence.filter(record => occurrenceIds.has(record.occurrenceId))).map(clone),
reviews: byId(state.reviews.filter(review => review.target.kind === 'occurrence'
? occurrenceIds.has(review.target.occurrenceId)
@@ -330,6 +339,27 @@ export class LocalAssessorRepository implements AssessorRepository {
return assessmentModel(this.state, assessmentId);
}
+ async getCveEnrichment(value: string): Promise {
+ const cveId = normalizeCveId(value);
+ return cveId ? clone(this.state.cveEnrichments.find(record => record.cveId === cveId) ?? null) : null;
+ }
+
+ async listCveEnrichments(values: string[]): Promise {
+ const ids = new Set(values.map(normalizeCveId).filter((value): value is string => Boolean(value)));
+ return this.state.cveEnrichments.filter(record => ids.has(record.cveId)).map(clone)
+ .sort((left, right) => left.cveId.localeCompare(right.cveId));
+ }
+
+ async saveCveEnrichment(record: CveEnrichmentRecord): Promise {
+ const errors = cveEnrichmentValidationErrors(record);
+ if (errors.length) throw new RepositoryValidationError(errors.join(' '));
+ const next = clone(this.state);
+ const index = next.cveEnrichments.findIndex(item => item.cveId === record.cveId);
+ if (index >= 0) next.cveEnrichments[index] = clone(record);
+ else next.cveEnrichments.push(clone(record));
+ this.replaceState(next);
+ }
+
async beginImport(start: ImportSessionStart): Promise {
if (!start.sessionId.trim()) throw new RepositoryValidationError('Eine Importsitzung benötigt eine ID.');
if (this.activeImportSessions.has(start.sessionId)) throw new RepositoryConflictError(`Importsitzung ${start.sessionId} ist bereits aktiv.`);
@@ -550,7 +580,10 @@ export class LocalAssessorRepository implements AssessorRepository {
importFile,
definition,
occurrence,
- reviews: this.state.reviews
+ reviews: this.state.reviews,
+ cveEnrichment: this.state.cveEnrichments.find(item => item.cveId === cveIdFromRuleId(
+ occurrence.sourceIdentity.canonicalRuleId ?? occurrence.sourceIdentity.originalRuleId
+ ))
})];
});
}
@@ -1286,6 +1319,10 @@ export class LocalAssessorRepository implements AssessorRepository {
...findingOccurrences.map(item => item.definitionId),
...policyFindingRuns.flatMap(item => item.occurrences.map(occurrence => occurrence.definitionId))
]);
+ const cveIds = new Set(findingOccurrences.flatMap(item => {
+ const id = cveIdFromRuleId(item.sourceIdentity.canonicalRuleId ?? item.sourceIdentity.originalRuleId);
+ return id ? [id] : [];
+ }));
return clone({
version: 1,
project,
@@ -1297,6 +1334,7 @@ export class LocalAssessorRepository implements AssessorRepository {
environmentObservations: byId(this.state.environmentObservations.filter(item => runIds.has(item.scanRunId))),
findingDefinitions: byId(this.state.findingDefinitions.filter(item => definitionIds.has(item.id))),
findingOccurrences: byId(findingOccurrences),
+ cveEnrichments: this.state.cveEnrichments.filter(item => cveIds.has(item.cveId)).map(clone),
evidence: byId(this.state.evidence.filter(item => occurrenceIds.has(item.occurrenceId))),
reviews: await this.listReviews(projectId),
diagnostics: byId(this.state.diagnostics.filter(item => fileIds.has(item.importFileId))),
diff --git a/tests/api/assessor-api-client.test.ts b/tests/api/assessor-api-client.test.ts
index a039d06..1ceaea6 100644
--- a/tests/api/assessor-api-client.test.ts
+++ b/tests/api/assessor-api-client.test.ts
@@ -266,4 +266,19 @@ describe('AssessorApiClient', () => {
projectId: 'project/one', assessmentId: 'assessment/one', cascade: true
});
});
+ it('reads and refreshes shared CVE enrichment through same-origin endpoints', async () => {
+ const fetcher = vi.fn().mockResolvedValue(new Response(JSON.stringify({
+ version: 1, record: { cveId: 'CVE-2012-3037' }
+ }), { status: 200, headers: { 'Content-Type': 'application/json' } }));
+ const client = new AssessorApiClient({ fetcher });
+
+ await client.getCveEnrichment('CVE-2012-3037');
+ await client.enrichCve('CVE-2012-3037');
+
+ expect(fetcher.mock.calls[0][0]).toBe('/api/v1/cves/CVE-2012-3037');
+ expect(new Headers(fetcher.mock.calls[0][1]?.headers).has('X-Assessor-Request')).toBe(false);
+ expect(fetcher.mock.calls[1][0]).toBe('/api/v1/cves/CVE-2012-3037/enrich');
+ expect(fetcher.mock.calls[1][1]?.method).toBe('POST');
+ expect(new Headers(fetcher.mock.calls[1][1]?.headers).get('X-Assessor-Request')).toBe('1');
+ });
});
diff --git a/tests/features/cve-enrichment-display-order.test.ts b/tests/features/cve-enrichment-display-order.test.ts
new file mode 100644
index 0000000..1d6b1ee
--- /dev/null
+++ b/tests/features/cve-enrichment-display-order.test.ts
@@ -0,0 +1,40 @@
+import { describe, expect, it } from 'vitest';
+import type { CveEnrichmentRecord } from '../../src/domain/cve-enrichment';
+import { cveFieldsForDisplay } from '../../src/features/project-import/canonical-model-to-dataset';
+
+const enrichment: CveEnrichmentRecord = {
+ version: 2,
+ cveId: 'CVE-2012-3037',
+ source: 'nvd',
+ sourceIdentifier: 'CVE-2012-3037',
+ sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2012-3037',
+ apiVersion: '2.0',
+ publishedAt: '2012-09-25T11:07:46.470Z',
+ lastModifiedAt: '2026-06-16T23:42:32.803Z',
+ fetchedAt: '2026-09-10T10:00:00.000Z',
+ description: 'Synthetic description.',
+ vulnerabilityStatus: 'Modified',
+ metrics: [],
+ weaknesses: [],
+ references: [],
+ affectedConfigurations: [{
+ operator: 'AND', negate: false,
+ vulnerableMatches: [{ criteria: 'cpe:2.3:o:example:firmware:*:*:*:*:*:*:*:*' }],
+ runningOnWith: [{ criteria: 'cpe:2.3:h:example:device:*:*:*:*:*:*:*:*' }]
+ }],
+ attributes: {}
+};
+
+describe('CVE enrichment display order', () => {
+ it('places NVD Affected Configurations at the very bottom of the finding fields', () => {
+ const fields = cveFieldsForDisplay(enrichment);
+ expect(fields.at(-1)?.label).toBe('NVD Affected Configurations');
+ expect(fields.findIndex(field => field.label === 'NVD Record'))
+ .toBeLessThan(fields.findIndex(field => field.label === 'NVD Affected Configurations'));
+ const value = fields.at(-1)?.value;
+ expect(typeof value).toBe('string');
+ expect(value).toContain('### Configuration 1');
+ expect(value).toContain('| **Running on/with** | |');
+ expect(String(value).match(/\| CPE \| Version range \|/g)).toHaveLength(1);
+ });
+});
diff --git a/tests/features/finding-reader.test.ts b/tests/features/finding-reader.test.ts
index 2c09ce8..0b58bf5 100644
--- a/tests/features/finding-reader.test.ts
+++ b/tests/features/finding-reader.test.ts
@@ -49,6 +49,35 @@ describe('selectFindingFields', () => {
expect(additionalLabels).not.toContain('Duplicate description');
});
+ it('renders NVD Affected Configurations last in the normal Work finding summary', () => {
+ const enrichedRecord: FindingRecord = {
+ ...record,
+ fields: [
+ ...record.fields,
+ { index: 11, label: 'NVD Affected Configurations', value: '| CPE | Vulnerable |\n| --- | --- |\n| synthetic | Yes |' },
+ { index: 12, label: 'NVD Metrics', value: '| Score |\n| --- |\n| 4.3 |' }
+ ]
+ };
+ const selected = selectFindingFields(enrichedRecord, record.title);
+
+ expect(selected.summary.at(-1)?.label).toBe('NVD Affected Configurations');
+ expect(selected.remainingFields.map(field => field.label)).not.toContain('NVD Affected Configurations');
+
+ const html = renderToStaticMarkup(createElement(FindingReader, {
+ record: enrichedRecord,
+ title: enrichedRecord.title,
+ linkedSheets: [],
+ resultReferences: [],
+ search: '',
+ position: 0,
+ recordCount: 1,
+ onPrevious: () => undefined,
+ onNext: () => undefined,
+ onReview: () => undefined
+ }));
+ expect(html.indexOf('NVD Affected Configurations')).toBeGreaterThan(html.indexOf('NVD Metrics'));
+ });
+
it('keeps generated CIS-CAT Results references out of the finding text', () => {
const cisCatRecord: FindingRecord = {
...record,
diff --git a/tests/features/results-browser-cve-enrichment.test.ts b/tests/features/results-browser-cve-enrichment.test.ts
new file mode 100644
index 0000000..509dc22
--- /dev/null
+++ b/tests/features/results-browser-cve-enrichment.test.ts
@@ -0,0 +1,25 @@
+import { describe, expect, it } from 'vitest';
+import { shouldShowNvdDescription } from '../../src/features/results-browser/ResultsBrowser';
+
+describe('Result DB CVE enrichment', () => {
+ it('does not repeat the NVD description when the scanner already supplied it', () => {
+ expect(shouldShowNvdDescription(
+ 'The same vulnerability description is already present.',
+ ' The same vulnerability description\n is already present. '
+ )).toBe(false);
+ });
+
+ it('ignores invisible Unicode, case, and punctuation differences in equivalent descriptions', () => {
+ expect(shouldShowNvdDescription(
+ 'Wind River VxWorks 6.7 though 6.9 and vx7 has a Buffer Over\u00adflow in the TCP component (issue 3 of 4).',
+ 'wind river vxworks 6.7 though 6.9 and VX7 has a buffer overflow in the TCP component — issue 3 of 4.'
+ )).toBe(false);
+ });
+
+ it('keeps a distinct NVD description visible', () => {
+ expect(shouldShowNvdDescription(
+ 'Scanner-provided description.',
+ 'NVD provides different details.'
+ )).toBe(true);
+ });
+});
diff --git a/tests/local-only-check.mjs b/tests/local-only-check.mjs
index 4bf7a99..0a857b7 100644
--- a/tests/local-only-check.mjs
+++ b/tests/local-only-check.mjs
@@ -109,6 +109,12 @@ assert.doesNotMatch(httpServer, /Access-Control-Allow-Origin/i, 'the local serve
assert.match(httpServer, /ASSESSOR_MUTATION_HEADER/, 'mutating API requests must retain the same-origin request guard');
assert.match(httpServer, /isValidImportBase64/, 'large Base64 import payloads must use iterative validation');
assert.doesNotMatch(httpServer, /\[A-Za-z0-9\+\/\]\{4\}.*\*/, 'Base64 validation must not use an unbounded repeated-group regex');
+const nvdCveClient = read(join('server', 'cve', 'nvd-cve-client.ts'));
+assert.match(nvdCveClient, /const NVD_CVE_API = 'https:\/\/services\.nvd\.nist\.gov\/rest\/json\/cves\/2\.0'/,
+ 'the approved NVD client must retain its fixed backend origin');
+assert.match(nvdCveClient, /MAXIMUM_RESPONSE_BYTES/, 'NVD responses must remain size-bounded');
+assert.match(nvdCveClient, /AbortSignal\.timeout/, 'NVD requests must retain a timeout');
+assert.doesNotMatch(nvdCveClient, /new URL\([^N]/, 'the NVD client must not construct request targets from user input');
const postgresRepository = read(join('server', 'postgres', 'postgres-assessor-repository.ts'));
assert.doesNotMatch(postgresRepository, /\\$\\{query\\./, 'PostgreSQL queries must not interpolate fields directly from request queries');
assert.match(postgresRepository, /FOR UPDATE/, 'PostgreSQL mutations must serialize repository revision updates');
diff --git a/tests/persistence/assessor-repository.test.ts b/tests/persistence/assessor-repository.test.ts
index 0a7c251..c5f6cc3 100644
--- a/tests/persistence/assessor-repository.test.ts
+++ b/tests/persistence/assessor-repository.test.ts
@@ -359,4 +359,52 @@ describe('LocalAssessorRepository contract', () => {
await expect(repository.listProjectImportFiles(project.id)).resolves.toEqual([]);
await expect(repository.getProject(project.id)).resolves.not.toBeNull();
});
+ it('reuses one shared CVE enrichment across Defender findings from different tenants', async () => {
+ const repository = await repositoryWithProject();
+ const secondProject = { ...project, id: 'project-2', name: 'Project 2' };
+ const secondAssessment = { ...assessment, id: 'assessment-2', projectId: secondProject.id };
+ await repository.saveProject(secondProject);
+ await repository.saveAssessment(secondAssessment);
+
+ const firstRun: ScanRun = {
+ ...scanRun(1), id: 'run-defender-1', tool: { id: 'defender-for-iot-vulnerabilities', name: 'Defender for IoT' }
+ };
+ const secondRun: ScanRun = {
+ ...firstRun, id: 'run-defender-2', assessmentId: secondAssessment.id
+ };
+ const defenderData = (run: ScanRun) => {
+ const data = importData(run, { occurrenceId: `occurrence-${run.id}`, ruleId: 'CVE-2012-3037' });
+ data.findingDefinitions[0] = {
+ ...data.findingDefinitions[0], canonicalKey: 'defender-for-iot-vulnerabilities:cve-2012-3037', title: 'CVE-2012-3037'
+ };
+ data.importFiles[0] = {
+ ...data.importFiles[0], detectedTool: run.tool,
+ processedWith: { ...data.importFiles[0].processedWith, profileId: 'defender-for-iot-vulnerabilities' }
+ };
+ data.findingOccurrences[0].sourceIdentity.tool = run.tool;
+ return data;
+ };
+ await commitRun(repository, firstRun, defenderData(firstRun));
+ const session = await repository.beginImport({
+ sessionId: 'session-defender-2', projectId: secondProject.id, assessmentId: secondAssessment.id, scanRun: secondRun
+ });
+ await session.stage(defenderData(secondRun));
+ await session.commit();
+
+ await repository.saveCveEnrichment({
+ version: 1, cveId: 'CVE-2012-3037', source: 'nvd', sourceIdentifier: 'nvd@nist.gov',
+ sourceUrl: 'https://nvd.nist.gov/vuln/detail/cve-2012-3037', apiVersion: '2.0', vulnerabilityStatus: 'Deferred',
+ publishedAt: '2012-08-25T10:55:01.000Z', lastModifiedAt: '2025-04-11T00:51:21.963Z', fetchedAt: timestamp,
+ description: 'Shared NVD description', metrics: [], weaknesses: [], references: [], affectedConfigurations: [], attributes: {}
+ });
+
+ await expect(repository.queryUnifiedResults({ projectId: project.id })).resolves.toMatchObject({
+ items: [expect.objectContaining({ cveEnrichment: expect.objectContaining({ cveId: 'CVE-2012-3037', description: 'Shared NVD description' }) })]
+ });
+ await expect(repository.queryUnifiedResults({ projectId: secondProject.id })).resolves.toMatchObject({
+ items: [expect.objectContaining({ cveEnrichment: expect.objectContaining({ cveId: 'CVE-2012-3037', description: 'Shared NVD description' }) })]
+ });
+ expect((await repository.loadAssessmentModel(assessment.id))?.cveEnrichments).toHaveLength(1);
+ expect((await repository.loadAssessmentModel(secondAssessment.id))?.cveEnrichments).toHaveLength(1);
+ });
});
diff --git a/tests/postgres/cve-enrichment-schema.test.ts b/tests/postgres/cve-enrichment-schema.test.ts
new file mode 100644
index 0000000..dc384b8
--- /dev/null
+++ b/tests/postgres/cve-enrichment-schema.test.ts
@@ -0,0 +1,12 @@
+import { describe, expect, it } from 'vitest';
+import { databaseMigrations } from '../../server/postgres/migration-catalog';
+
+describe('CVE enrichment schema', () => {
+ it('stores one global NVD record per normalized CVE without tenant ownership', () => {
+ const migration = databaseMigrations.find(item => item.version === '021');
+ expect(migration?.sql).toContain('CREATE TABLE assessor_cve_enrichments');
+ expect(migration?.sql).toContain('cve_id text PRIMARY KEY');
+ expect(migration?.sql).not.toMatch(/project_id|assessment_id|scan_run_id/);
+ expect(migration?.sql).toContain("source = 'nvd'");
+ });
+});
diff --git a/tests/server/nvd-cve-client.test.ts b/tests/server/nvd-cve-client.test.ts
new file mode 100644
index 0000000..9a6461d
--- /dev/null
+++ b/tests/server/nvd-cve-client.test.ts
@@ -0,0 +1,61 @@
+import { describe, expect, it, vi } from 'vitest';
+import { NvdCveClient, NvdCveClientError, parseNvdCveResponse } from '../../server/cve/nvd-cve-client';
+
+const payload = {
+ version: '2.0',
+ vulnerabilities: [{ cve: {
+ id: 'CVE-2012-3037', sourceIdentifier: 'nvd@nist.gov', published: '2012-08-25T10:55:01.000',
+ lastModified: '2025-04-11T00:51:21.963', vulnStatus: 'Deferred',
+ descriptions: [{ lang: 'en', value: 'Synthetic vulnerability description.' }],
+ metrics: {
+ cvssMetricV31: [{ source: 'nvd@nist.gov', type: 'Primary', exploitabilityScore: 3.9, impactScore: 5.9,
+ cvssData: { version: '3.1', vectorString: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H', baseScore: 9.8, baseSeverity: 'CRITICAL' } }]
+ },
+ weaknesses: [{ source: 'nvd@nist.gov', type: 'Primary', description: [{ lang: 'en', value: 'CWE-119' }] }],
+ references: [{ url: 'https://vendor.example/advisory', source: 'nvd@nist.gov', tags: ['Vendor Advisory', 'Patch'] }],
+ configurations: [{ operator: 'AND', nodes: [
+ { cpeMatch: [{
+ vulnerable: true, criteria: 'cpe:2.3:a:vendor:product:*:*:*:*:*:*:*:*', versionEndExcluding: '2.0'
+ }] },
+ { cpeMatch: [{ vulnerable: false, criteria: 'cpe:2.3:h:vendor:device:*:*:*:*:*:*:*:*' }] }
+ ] }],
+ cisaRequiredAction: 'Apply vendor guidance.'
+ } }]
+};
+
+describe('NVD CVE enrichment', () => {
+ it('normalizes the bounded NVD 2.0 response into shared CVE knowledge', () => {
+ const record = parseNvdCveResponse(payload, 'CVE-2012-3037', '2026-09-10T08:00:00.000Z');
+ expect(record).toMatchObject({
+ cveId: 'CVE-2012-3037', source: 'nvd', description: 'Synthetic vulnerability description.',
+ metrics: [{ version: '3.1', baseScore: 9.8, baseSeverity: 'CRITICAL' }],
+ weaknesses: [{ id: 'CWE-119' }],
+ references: [{ url: 'https://vendor.example/advisory', tags: ['Vendor Advisory', 'Patch'] }],
+ affectedConfigurations: [{
+ operator: 'AND',
+ vulnerableMatches: [{ criteria: 'cpe:2.3:a:vendor:product:*:*:*:*:*:*:*:*', versionEndExcluding: '2.0' }],
+ runningOnWith: [{ criteria: 'cpe:2.3:h:vendor:device:*:*:*:*:*:*:*:*' }]
+ }],
+ attributes: { cisaRequiredAction: 'Apply vendor guidance.' }
+ });
+ });
+
+ it('calls only the fixed NVD endpoint with an encoded exact CVE and optional API key', async () => {
+ const fetcher = vi.fn().mockResolvedValue(new Response(JSON.stringify(payload), {
+ status: 200, headers: { 'Content-Type': 'application/json' }
+ }));
+ const client = new NvdCveClient({ fetcher, apiKey: 'test-key', now: () => new Date('2026-09-10T08:00:00.000Z') });
+ await expect(client.fetchCve('cve-2012-3037')).resolves.toMatchObject({ cveId: 'CVE-2012-3037' });
+ const url = fetcher.mock.calls[0][0] as URL;
+ expect(url.origin + url.pathname).toBe('https://services.nvd.nist.gov/rest/json/cves/2.0');
+ expect(url.searchParams.get('cveId')).toBe('CVE-2012-3037');
+ expect(new Headers(fetcher.mock.calls[0][1]?.headers).get('apiKey')).toBe('test-key');
+ });
+
+ it('rejects invalid identifiers before making a network request', async () => {
+ const fetcher = vi.fn();
+ const client = new NvdCveClient({ fetcher });
+ await expect(client.fetchCve('not-a-cve')).rejects.toMatchObject({ code: 'invalid_cve_id' } satisfies Partial);
+ expect(fetcher).not.toHaveBeenCalled();
+ });
+});
--
2.39.5
From fe712464627ecfea80b4f1169e94c3d77482a428 Mon Sep 17 00:00:00 2001
From: Binh
Date: Fri, 11 Sep 2026 10:15:29 +0200
Subject: [PATCH 04/33] feat(defender-for-iot): introduce vulnerability finding
result type and update related schemas and logic
---
docs/IMPLEMENTATION_PLAN.md | 1 +
server/postgres/migration-catalog.ts | 4 ++-
.../022_vulnerability_finding_result_type.sql | 12 +++++++
src/domain/canonical-validation.ts | 2 +-
src/domain/processing-compatibility.ts | 3 +-
src/domain/result-contract-mapping.ts | 5 +++
src/domain/tool-profile-definition.ts | 4 ++-
src/importers/status-normalization.ts | 32 +++++++++++++++++--
.../defender-for-iot-definition.ts | 10 +++---
src/profiles/profile-factory.ts | 25 ++-------------
tests/domain/deviation-predicate.test.ts | 13 +++++++-
tests/domain/processing-compatibility.test.ts | 14 +++++---
tests/domain/result-contract-mapping.test.ts | 12 +++++--
.../datahub-processing-readiness.test.ts | 4 ++-
tests/features/dynamic-facets.test.ts | 4 ++-
tests/importers/defender-for-iot.test.ts | 26 +++++++++++++--
.../vulnerability-finding-schema.test.ts | 30 +++++++++++++++++
tests/profiles/declarative-profiles.test.ts | 8 +++++
18 files changed, 163 insertions(+), 46 deletions(-)
create mode 100644 server/postgres/migrations/022_vulnerability_finding_result_type.sql
create mode 100644 tests/postgres/vulnerability-finding-schema.test.ts
diff --git a/docs/IMPLEMENTATION_PLAN.md b/docs/IMPLEMENTATION_PLAN.md
index ee41a25..514a0fa 100644
--- a/docs/IMPLEMENTATION_PLAN.md
+++ b/docs/IMPLEMENTATION_PLAN.md
@@ -1835,6 +1835,7 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode
## 12. Änderungsprotokoll
| Datum | Änderung |
+| 2026-09-11 | Phase-7-Abweichungsfilter zwischen Work und Result DB vereinheitlicht: Work prueft `deviation` nicht mehr gegen beliebige profilbezogene Rohwertmuster wie Defender-Severity `Critical`, sondern rekonstruiert aus Werkzeug und Statusfeld dieselben kanonischen Achsen Outcome, Result Type, Exposure State und `is_ioe` und verwendet anschliessend das gemeinsame versionierte Abweichungspraedikat. Defender-CVEs ohne Status bleiben damit wie in der Result DB `outcome=unknown`, `is_ioe=false`, `deviation=false`; Fail-/Warning-Ergebnisse und festgestellte Expositionen bleiben Abweichungen. Keine Daten-, API-, Schema-, Persistenz- oder Profilversionsaenderung. 781 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Phase 7 bleibt abgeschlossen. |
| 2026-09-10 | Result-DB-Beschreibungsdeduplizierung fuer einzelne Defender-CVEs nachgehaertet: Scanner- und NVD-Beschreibung werden fuer den reinen Anzeigevergleich jetzt Unicode-NFKC-normalisiert, von unsichtbaren Formatzeichen bereinigt, case-insensitiv behandelt und ueber ihre Wort-/Zahlfolge verglichen. Dadurch werden visuell identische Saetze auch bei Soft-Hyphen-, Zeichensetzungs- oder Grossschreibungsabweichungen nicht doppelt gerendert; inhaltlich unterschiedliche Wortfolgen bleiben sichtbar. Gespeicherte Quelltexte bleiben unveraendert. Drei fokussierte Regressionstests und der Client-Produktionsbuild sind erfolgreich. |
| 2026-09-10 | Work-Darstellung der gruppierten NVD-Konfigurationen an die Originalstruktur angenaehert: Jede nummerierte `Configuration` rendert genau eine Tabelle. Nach den betroffenen CPE-Zeilen steht `Running on/with` als eigene Tabellenzeile; die zugeordneten Plattform-CPEs folgen innerhalb derselben Tabelle statt in einer zweiten Tabelle. Gruppierung, Speicherung und Reihenfolge der Findings bleiben unveraendert. 17 fokussierte Finding-/CVE-Darstellungstests und der Client-Produktionsbuild sind erfolgreich. |
| 2026-09-10 | NVD-Konfigurationsprojektion korrigiert: Der NVD-Adapter flacht CPE-Matches nicht mehr zu einzelnen Konfigurationen ab, sondern speichert jede top-level API-Konfiguration als eine Gruppe mit getrennten `vulnerableMatches` und `runningOnWith`. Work zeigt je Gruppe `Configuration n`, die betroffene Software mit Versionsbereich und darunter die zugehoerigen `Running on/with`-CPEs. Das Enrichmentformat ist Version 2; vorhandene Version-1-Daten bleiben defensiv lesbar und werden beim naechsten `Refresh from NVD` verlustfrei ersetzt. 33 fokussierte Parser-, Persistenz- und Darstellungsregressionen, beide TypeScript-Pruefungen sowie der vollstaendige Client-/Server-Produktionsbuild sind erfolgreich. Keine SQL-Migration und keine Aenderung der Scannerfindings. |
diff --git a/server/postgres/migration-catalog.ts b/server/postgres/migration-catalog.ts
index e4c72e7..38ed8f8 100644
--- a/server/postgres/migration-catalog.ts
+++ b/server/postgres/migration-catalog.ts
@@ -17,6 +17,7 @@ import policyEvaluationRuleCatalogs from './migrations/016_policy_evaluation_rul
import policyFindingFactory from './migrations/017_policy_finding_factory.sql?raw';
import scannerEnvironmentContext from './migrations/018_scanner_environment_context.sql?raw';
import cveEnrichment from './migrations/021_cve_enrichment.sql?raw';
+import vulnerabilityFindingResultType from './migrations/022_vulnerability_finding_result_type.sql?raw';
export interface DatabaseMigration {
version: string;
@@ -43,5 +44,6 @@ export const databaseMigrations: readonly DatabaseMigration[] = [
{ version: '016', name: 'policy-evaluation-rule-catalogs', sql: policyEvaluationRuleCatalogs },
{ version: '017', name: 'policy-finding-factory', sql: policyFindingFactory },
{ version: '018', name: 'scanner-environment-context', sql: scannerEnvironmentContext },
- { version: '021', name: 'cve-enrichment', sql: cveEnrichment }
+ { version: '021', name: 'cve-enrichment', sql: cveEnrichment },
+ { version: '022', name: 'vulnerability-finding-result-type', sql: vulnerabilityFindingResultType }
];
diff --git a/server/postgres/migrations/022_vulnerability_finding_result_type.sql b/server/postgres/migrations/022_vulnerability_finding_result_type.sql
new file mode 100644
index 0000000..04bfbf0
--- /dev/null
+++ b/server/postgres/migrations/022_vulnerability_finding_result_type.sql
@@ -0,0 +1,12 @@
+-- ASSESSOR-Erweiterung des geschlossenen RESULT_CONTRACT-result_type-Katalogs
+-- fuer Scannerbefunde zu konkreten Schwachstellen. Bestehende Occurrences
+-- werden nicht umgedeutet; der neue Typ gilt fuer neu verarbeitete Importe.
+
+ALTER TABLE assessor_finding_occurrences
+ DROP CONSTRAINT assessor_occurrences_result_type_check,
+ ADD CONSTRAINT assessor_occurrences_result_type_check CHECK (
+ result_type IN (
+ 'exposure_finding', 'vulnerability_finding', 'compliance_check',
+ 'policy_deviation', 'informational', 'unknown'
+ )
+ );
diff --git a/src/domain/canonical-validation.ts b/src/domain/canonical-validation.ts
index 74cccf0..09b0bb9 100644
--- a/src/domain/canonical-validation.ts
+++ b/src/domain/canonical-validation.ts
@@ -8,7 +8,7 @@ import type {
import { processingManifest } from './processing-compatibility';
const RESULT_CONTRACT_RESULT_TYPES = new Set([
- 'exposure_finding', 'compliance_check', 'policy_deviation', 'informational', 'unknown'
+ 'exposure_finding', 'vulnerability_finding', 'compliance_check', 'policy_deviation', 'informational', 'unknown'
]);
const RESULT_CONTRACT_EXPOSURE_STATES = new Set([
'detected', 'not_detected', 'not_evaluated', 'execution_error', 'unknown'
diff --git a/src/domain/processing-compatibility.ts b/src/domain/processing-compatibility.ts
index b8809fe..8d143ac 100644
--- a/src/domain/processing-compatibility.ts
+++ b/src/domain/processing-compatibility.ts
@@ -24,7 +24,8 @@ export interface ProcessingVersionManifest extends ToolProcessingContract {
*/
export const PROCESSING_VERSION_MANIFESTS: readonly ProcessingVersionManifest[] = [
{ profileId: 'generic', profileVersion: '1.0.0', mappingVersion: '1.0.0', normalizationVersion: '1.0.0', presentationVersion: '1.0.0', compatibilityKey: 'generic-canonical-v1', changeClass: 'compatible', reimportRequired: false, affectedDimensions: [], current: true },
- { profileId: 'defender-for-iot-vulnerabilities', profileVersion: '1.0.0', mappingVersion: '1.0.0', normalizationVersion: '1.0.0', presentationVersion: '1.0.0', compatibilityKey: 'defender-for-iot-vulnerabilities-v1', changeClass: 'compatible', reimportRequired: false, affectedDimensions: [], current: true },
+ { profileId: 'defender-for-iot-vulnerabilities', profileVersion: '1.0.0', mappingVersion: '1.0.0', normalizationVersion: '1.0.0', presentationVersion: '1.0.0', compatibilityKey: 'defender-for-iot-vulnerabilities-v1', changeClass: 'compatible', reimportRequired: false, affectedDimensions: [], current: false },
+ { profileId: 'defender-for-iot-vulnerabilities', profileVersion: '1.1.0', mappingVersion: '1.0.0', normalizationVersion: '1.1.0', presentationVersion: '1.0.0', compatibilityKey: 'defender-for-iot-vulnerabilities-v2', changeClass: 'semantic-breaking', reimportRequired: true, affectedDimensions: ['outcome', 'resultType', 'deviation'], current: true },
{ profileId: 'purple-knight', profileVersion: '1.0.0', mappingVersion: '1.0.0', normalizationVersion: '1.0.0', presentationVersion: '1.0.0', compatibilityKey: 'purple-knight-canonical-v1', changeClass: 'semantic-breaking', reimportRequired: true, affectedDimensions: ['outcome', 'isIoe'], current: false },
{ profileId: 'purple-knight', profileVersion: '1.1.0', mappingVersion: '1.1.0', normalizationVersion: '1.1.0', presentationVersion: '1.1.0', compatibilityKey: 'purple-knight-canonical-v1.1', changeClass: 'semantic-breaking', reimportRequired: true, affectedDimensions: ['outcome', 'isIoe'], current: true },
{ profileId: 'pingcastle', profileVersion: '1.0.0', mappingVersion: '1.0.0', normalizationVersion: '1.0.0', presentationVersion: '1.0.0', compatibilityKey: 'pingcastle-canonical-v1', changeClass: 'semantic-breaking', reimportRequired: true, affectedDimensions: ['outcome', 'isIoe'], current: false },
diff --git a/src/domain/result-contract-mapping.ts b/src/domain/result-contract-mapping.ts
index 85e9949..14946e3 100644
--- a/src/domain/result-contract-mapping.ts
+++ b/src/domain/result-contract-mapping.ts
@@ -20,6 +20,7 @@ export const RESULT_CONTRACT_MAPPING_VERSION = '1.0.0';
export type ResultContractResultType =
| 'exposure_finding'
+ | 'vulnerability_finding'
| 'compliance_check'
| 'policy_deviation'
| 'informational'
@@ -49,6 +50,9 @@ export interface ResultContractIoeDerivation {
*/
const EXPOSURE_TOOL_IDS = new Set(['pingcastle', 'purple-knight', 'maester']);
+/** Scanner, deren native Aussage eine konkrete Schwachstelle bezeichnet. */
+const VULNERABILITY_TOOL_IDS = new Set(['defender-for-iot-vulnerabilities']);
+
/**
* Werkzeuge, deren native Aussage RESULT_CONTRACT als `compliance_check`
* einordnet.
@@ -65,6 +69,7 @@ const COMPLIANCE_TOOL_IDS = new Set(['cis-cat']);
export function deriveResultType(toolId: string): ResultContractResultType {
const normalized = toolId.trim().toLocaleLowerCase('en-US');
if (EXPOSURE_TOOL_IDS.has(normalized)) return 'exposure_finding';
+ if (VULNERABILITY_TOOL_IDS.has(normalized)) return 'vulnerability_finding';
if (COMPLIANCE_TOOL_IDS.has(normalized)) return 'compliance_check';
return 'unknown';
}
diff --git a/src/domain/tool-profile-definition.ts b/src/domain/tool-profile-definition.ts
index ec063f1..117eb2e 100644
--- a/src/domain/tool-profile-definition.ts
+++ b/src/domain/tool-profile-definition.ts
@@ -1,4 +1,4 @@
-import type { CanonicalFieldRole, CanonicalFindingStatus, CanonicalSeverity } from './canonical-model';
+import type { CanonicalFieldRole, CanonicalFindingStatus, CanonicalOutcome, CanonicalSeverity } from './canonical-model';
export type ProfileSignalScope = 'file-name' | 'raw-text' | 'table-name' | 'header' | 'cell-value';
@@ -68,6 +68,8 @@ export interface ToolProfileDefinition {
normalization: {
severity: Array>;
status: Array>;
+ /** Outcome fuer Finding-Quellen, deren Zeilen selbst der Befund sind und keinen Status liefern. */
+ missingStatusOutcome?: CanonicalOutcome;
};
presentation: {
titleHeaders: RegExp[];
diff --git a/src/importers/status-normalization.ts b/src/importers/status-normalization.ts
index 483ac81..8e33a6f 100644
--- a/src/importers/status-normalization.ts
+++ b/src/importers/status-normalization.ts
@@ -4,6 +4,8 @@ import type {
CanonicalTechnicalExecutionState
} from '../domain/canonical-model';
import type { FindingRecord } from '../domain/finding';
+import { isDeviation } from '../domain/deviation-predicate';
+import { deriveExposureState, deriveIsIoe, deriveResultType } from '../domain/result-contract-mapping';
import { outcomeFromLegacyStatus, technicalStateFromLegacyStatus } from '../domain/unified-result';
import { toolProfileDefinitions } from '../profiles/profile-definition-catalog';
import { clean } from '../shared/text';
@@ -73,9 +75,12 @@ function dimensionsFor(legacy: CanonicalFindingStatus, outcome?: CanonicalOutcom
*/
export function normalizeStatusDimensionsFor(toolId: string | undefined, value: string): StatusDimensions {
const cleaned = clean(value);
- if (!cleaned) return UNKNOWN_DIMENSIONS;
+ const definition = toolId ? definitionsByToolId.get(toolId) : undefined;
+ if (!cleaned) return definition?.normalization.missingStatusOutcome
+ ? { legacy: 'unknown', outcome: definition.normalization.missingStatusOutcome, technical: 'completed' }
+ : UNKNOWN_DIMENSIONS;
- const declared = toolId ? definitionsByToolId.get(toolId)?.normalization.status : undefined;
+ const declared = definition?.normalization.status;
const declaredMatch = declared?.find(mapping => mapping.patterns.some(pattern => pattern.test(cleaned)));
if (declaredMatch) return dimensionsFor(declaredMatch.normalizedValue);
@@ -111,6 +116,29 @@ export function toolIdForRecord(record: FindingRecord, fallbackToolId?: string):
return toolIdByName.get(toolName) ?? fallbackToolId;
}
+function statusValueForRecord(record: FindingRecord, toolId: string | undefined): string {
+ const presentation = toolId ? definitionsByToolId.get(toolId)?.presentation : undefined;
+ const headers = presentation?.statusHeaders ?? [/^(?:status|evaluation|result)$/i];
+ for (const header of headers) {
+ const field = record.fields.find(candidate =>
+ candidate.value
+ && header.test(candidate.label.trim())
+ && !presentation?.resultMessageHeaders?.some(pattern => pattern.test(candidate.label.trim())));
+ if (field) return field.value;
+ }
+ return '';
+}
+
+/** Spiegelt fuer rohe Work-Datensaetze das kanonische Result-DB-Praedikat. */
+export function isDeviationRecord(record: FindingRecord, fallbackToolId?: string): boolean {
+ const toolId = toolIdForRecord(record, fallbackToolId);
+ const outcome = normalizeStatusDimensionsFor(toolId, statusValueForRecord(record, toolId)).outcome;
+ const resultType = deriveResultType(toolId ?? '');
+ const exposureState = deriveExposureState(resultType, outcome);
+ const isIoe = deriveIsIoe(resultType, exposureState).isIoe;
+ return isDeviation(isIoe, outcome);
+}
+
/**
* Outcome eines rohen Statusfeldes, wie es die Arbeitsansichten anzeigen.
*
diff --git a/src/profiles/defender-for-iot/defender-for-iot-definition.ts b/src/profiles/defender-for-iot/defender-for-iot-definition.ts
index c2ed3f6..7b71219 100644
--- a/src/profiles/defender-for-iot/defender-for-iot-definition.ts
+++ b/src/profiles/defender-for-iot/defender-for-iot-definition.ts
@@ -5,11 +5,11 @@ export const defenderForIotDefinition: ToolProfileDefinition = {
schemaVersion: 1,
id: 'defender-for-iot-vulnerabilities',
name: 'Microsoft Defender for IoT',
- version: '1.0.0',
+ version: '1.1.0',
processing: {
- mappingVersion: '1.0.0', normalizationVersion: '1.0.0', presentationVersion: '1.0.0',
- compatibilityKey: 'defender-for-iot-vulnerabilities-v1', changeClass: 'compatible',
- reimportRequired: false, affectedDimensions: []
+ mappingVersion: '1.0.0', normalizationVersion: '1.1.0', presentationVersion: '1.0.0',
+ compatibilityKey: 'defender-for-iot-vulnerabilities-v2', changeClass: 'semantic-breaking',
+ reimportRequired: true, affectedDimensions: ['outcome', 'resultType', 'deviation']
},
sourceSignals: [
{ scope: 'header', pattern: /^TotalCVEs$/i, contribution: 0.45, message: 'The asset summary exposes TotalCVEs.' },
@@ -32,7 +32,7 @@ export const defenderForIotDefinition: ToolProfileDefinition = {
{ role: 'asset', headers: [{ pattern: /^Affected Device Count$/i, contribution: 0.92, message: 'The aggregated affected-device count stands in for the affected object of this CVE.' }] },
{ role: 'evidence', headers: [{ pattern: /^Source Observations$/i, contribution: 1, message: 'The field preserves every sensor observation and row locator.' }] }
],
- normalization: { severity: commonSeverityMappings, status: commonStatusMappings },
+ normalization: { severity: commonSeverityMappings, status: commonStatusMappings, missingStatusOutcome: 'warning' },
presentation: {
titleHeaders: [/^CVE$/i],
severityHeaders: [/^Severity$/i],
diff --git a/src/profiles/profile-factory.ts b/src/profiles/profile-factory.ts
index 8f4cde9..7d60cc2 100644
--- a/src/profiles/profile-factory.ts
+++ b/src/profiles/profile-factory.ts
@@ -2,6 +2,7 @@ import type { DatasetSheet } from '../domain/dataset';
import type { FindingRecord } from '../domain/finding';
import type { ImportProfile, ProfileDetectionContext } from '../domain/import-profile';
import type { ToolProfileDefinition, WeightedPattern } from '../domain/tool-profile-definition';
+import { isDeviationRecord } from '../importers/status-normalization';
import { clean, plainTextValue } from '../shared/text';
function matches(pattern: RegExp, value: string): boolean {
@@ -24,25 +25,6 @@ function matches(pattern: RegExp, value: string): boolean {
*/
const normalizedFieldValuesCache = new WeakMap();
-/**
- * Werkzeuguebergreifender Arbeitsfilter. Die Muster entsprechen der fachlichen
- * Abweichung: fehlgeschlagene oder klaerungsbeduerftige Resultate sowie
- * festgestellte Expositionen. Der Filter ist in jedem Profil verfuegbar und
- * bildet den unveraenderlichen Startzustand aller Diagramme.
- */
-const UNIVERSAL_DEVIATION_PATTERNS = [
- /^fail(?:ed)?$/,
- /^not passed?$/,
- /^nicht bestanden$/,
- /^ioes? (?:found|detected)$/,
- /^matched$/,
- /^detected$/,
- /^open$/,
- /^offen$/,
- /^investigate$/,
- /^warning$/
-];
-
function normalizedFieldValues(record: FindingRecord): string[] {
let cached = normalizedFieldValuesCache.get(record);
if (!cached) {
@@ -121,11 +103,9 @@ export function createImportProfile(definition: ToolProfileDefinition): ImportPr
}),
matchesStatus: (record, status) => {
if (status === 'all') return true;
+ if (status === 'deviation') return isDeviationRecord(record, definition.id);
const filter = definition.presentation.statusFilters.find(item => item.value === status);
const values = normalizedFieldValues(record);
- if (status === 'deviation' && !filter) {
- return values.some(value => UNIVERSAL_DEVIATION_PATTERNS.some(pattern => matches(pattern, value)));
- }
if (!filter) return true;
return values.some(value => filter.patterns.some(pattern => matches(pattern, value)));
},
@@ -136,4 +116,3 @@ export function createImportProfile(definition: ToolProfileDefinition): ImportPr
}
};
}
-
diff --git a/tests/domain/deviation-predicate.test.ts b/tests/domain/deviation-predicate.test.ts
index 8588704..ad6094a 100644
--- a/tests/domain/deviation-predicate.test.ts
+++ b/tests/domain/deviation-predicate.test.ts
@@ -2,7 +2,7 @@ import { describe, expect, it } from 'vitest';
import type { CanonicalOutcome } from '../../src/domain/canonical-model';
import { DEVIATION_PREDICATE_VERSION, isDeviation } from '../../src/domain/deviation-predicate';
import type { FindingRecord } from '../../src/domain/finding';
-import { normalizeStatusDimensionsFor, outcomeForStatusValue, toolIdForRecord } from '../../src/importers/status-normalization';
+import { isDeviationRecord, normalizeStatusDimensionsFor, outcomeForStatusValue, toolIdForRecord } from '../../src/importers/status-normalization';
function recordWith(fields: Array<[string, string]>): FindingRecord {
const built = fields.map(([label, value], index) => ({ label, value, index }));
@@ -69,6 +69,12 @@ describe('Maester-Statusvokabular', () => {
});
describe('Outcome eines rohen Statusfeldes fuer die Arbeitsansichten', () => {
+ it('wendet in Work dasselbe Praedikat wie die Result DB an', () => {
+ expect(isDeviationRecord(recordWith([['Severity', 'Critical']]), 'defender-for-iot-vulnerabilities')).toBe(true);
+ expect(isDeviationRecord(recordWith([['Result', 'Failed']]), 'cis-cat')).toBe(true);
+ expect(isDeviationRecord(recordWith([['Result', 'Passed']]), 'cis-cat')).toBe(false);
+ });
+
it('unterscheidet die drei Maester-Ergebnisse voneinander', () => {
expect(outcomeForStatusValue('maester', 'Passed')).toBe('pass');
expect(outcomeForStatusValue('maester', 'Failed')).toBe('fail');
@@ -80,6 +86,11 @@ describe('Outcome eines rohen Statusfeldes fuer die Arbeitsansichten', () => {
expect(outcomeForStatusValue('maester', ' ')).toBeUndefined();
});
+ it('normalisiert einen statuslosen Defender-CVE-Befund auf warning', () => {
+ expect(normalizeStatusDimensionsFor('defender-for-iot-vulnerabilities', ''))
+ .toEqual({ legacy: 'unknown', outcome: 'warning', technical: 'completed' });
+ });
+
it('bleibt ohne bekannte Werkzeug-ID ueber die generischen Regeln nutzbar', () => {
expect(outcomeForStatusValue(undefined, 'Investigate')).toBe('warning');
expect(outcomeForStatusValue(undefined, 'Passed')).toBe('pass');
diff --git a/tests/domain/processing-compatibility.test.ts b/tests/domain/processing-compatibility.test.ts
index d723086..fab6c97 100644
--- a/tests/domain/processing-compatibility.test.ts
+++ b/tests/domain/processing-compatibility.test.ts
@@ -40,10 +40,16 @@ describe('processing compatibility contracts', () => {
});
it('uses the recorded profile when a caller supplies a different detected tool id', () => {
- const defender = file('defender', 'defender-for-iot-vulnerabilities', '1.0.0', '1.0.0');
- expect(processingReadiness('microsoft-defender-for-iot', defender.processedWith)).toBe('current');
- expect(resolvedCompatibilityKey('microsoft-defender-for-iot', defender.processedWith))
- .toBe('defender-for-iot-vulnerabilities-v1');
+ const legacy = file('defender-old', 'defender-for-iot-vulnerabilities', '1.0.0', '1.0.0');
+ const current = file('defender-current', 'defender-for-iot-vulnerabilities', '1.1.0', '1.0.0');
+ current.processedWith.normalizationVersion = '1.1.0';
+ current.processedWith.presentationVersion = '1.0.0';
+ current.processedWith.compatibilityKey = 'defender-for-iot-vulnerabilities-v2';
+
+ expect(processingReadiness('microsoft-defender-for-iot', legacy.processedWith)).toBe('incompatible');
+ expect(processingReadiness('microsoft-defender-for-iot', current.processedWith)).toBe('current');
+ expect(resolvedCompatibilityKey('microsoft-defender-for-iot', current.processedWith))
+ .toBe('defender-for-iot-vulnerabilities-v2');
});
it('blocks semantically incompatible versions in one scope', () => {
diff --git a/tests/domain/result-contract-mapping.test.ts b/tests/domain/result-contract-mapping.test.ts
index ea6bf47..d3c1737 100644
--- a/tests/domain/result-contract-mapping.test.ts
+++ b/tests/domain/result-contract-mapping.test.ts
@@ -19,6 +19,10 @@ describe('RESULT_CONTRACT result_type derivation', () => {
expect(deriveResultType('cis-cat')).toBe('compliance_check');
});
+ it('maps Defender CVEs to vulnerability_finding', () => {
+ expect(deriveResultType('defender-for-iot-vulnerabilities')).toBe('vulnerability_finding');
+ });
+
it('falls back to unknown for unknown or generic tools, never inventing exposure/compliance', () => {
expect(deriveResultType('generic')).toBe('unknown');
expect(deriveResultType('some-future-tool')).toBe('unknown');
@@ -74,6 +78,10 @@ describe('RESULT_CONTRACT is_ioe invariant (never default true outside exposure_
expect(deriveIsIoe('unknown', undefined).isIoe).toBe(false);
});
+ it('is false for vulnerability_finding', () => {
+ expect(deriveIsIoe('vulnerability_finding', undefined).isIoe).toBe(false);
+ });
+
it('is false for exposure_finding without a detected exposure_state', () => {
expect(deriveIsIoe('exposure_finding', 'not_detected').isIoe).toBe(false);
expect(deriveIsIoe('exposure_finding', 'not_evaluated').isIoe).toBe(false);
@@ -91,8 +99,8 @@ describe('RESULT_CONTRACT is_ioe invariant (never default true outside exposure_
});
describe('exposure_state only exists for exposure_finding', () => {
- it('is undefined for compliance_check, policy_deviation, informational and unknown', () => {
- (['compliance_check', 'policy_deviation', 'informational', 'unknown'] as const).forEach(resultType => {
+ it('is undefined for non-exposure result types', () => {
+ (['vulnerability_finding', 'compliance_check', 'policy_deviation', 'informational', 'unknown'] as const).forEach(resultType => {
expect(deriveExposureState(resultType, 'fail')).toBeUndefined();
});
});
diff --git a/tests/features/datahub-processing-readiness.test.ts b/tests/features/datahub-processing-readiness.test.ts
index 81da8e2..3e3f0a1 100644
--- a/tests/features/datahub-processing-readiness.test.ts
+++ b/tests/features/datahub-processing-readiness.test.ts
@@ -40,9 +40,11 @@ describe('Datahub client processing readiness', () => {
it('assesses the stored profile contract independently from the detected tool identity', () => {
const defender = withDetectedTool(
- file('run-defender', 'defender-for-iot-vulnerabilities', '1.0.0', 'defender-for-iot-vulnerabilities-v1'),
+ file('run-defender', 'defender-for-iot-vulnerabilities', '1.1.0', 'defender-for-iot-vulnerabilities-v2'),
'microsoft-defender-for-iot'
);
+ defender.processedWith.mappingVersion = '1.0.0';
+ defender.processedWith.presentationVersion = '1.0.0';
expect(summarizeScanProcessingReadiness([defender])).toEqual({
state: 'ready', statuses: ['current'], explanation: 'The scan uses a current or compatible ASSESSOR processing profile.'
});
diff --git a/tests/features/dynamic-facets.test.ts b/tests/features/dynamic-facets.test.ts
index cb54239..0ef511f 100644
--- a/tests/features/dynamic-facets.test.ts
+++ b/tests/features/dynamic-facets.test.ts
@@ -24,7 +24,9 @@ describe('dynamic facets', () => {
// "Ergebnisstatus" diese Aufgabe. Zwei Filter fuer dieselbe Spalte waren
// fuer die Bedienung nicht unterscheidbar.
expect(facets.some(facet => facet.id === 'field:2')).toBe(false);
- expect(facets.find(facet => facet.id === 'profile:status')?.values.map(value => value.label)).toEqual(['Deviation']);
+ // "Open" normalisiert auf Outcome unknown und ist nach demselben
+ // kanonischen Praedikat wie in der Result DB keine Abweichung.
+ expect(facets.find(facet => facet.id === 'profile:status')?.values).toEqual([]);
expect(facets.some(facet => facet.id === 'field:3')).toBe(false);
expect(facets.some(facet => facet.id === 'field:4')).toBe(false);
});
diff --git a/tests/importers/defender-for-iot.test.ts b/tests/importers/defender-for-iot.test.ts
index 5a87d20..6babc00 100644
--- a/tests/importers/defender-for-iot.test.ts
+++ b/tests/importers/defender-for-iot.test.ts
@@ -9,6 +9,7 @@ import { importProfiles } from '../../src/profiles/profile-catalog';
import { confirmEntryMappings, previewEntryFromDataset } from '../../src/features/import-workflow/import-workflow';
import { canonicalModelToDataset } from '../../src/features/project-import/canonical-model-to-dataset';
import { summarizeScanProcessingReadiness } from '../../src/features/project-import/datahub-processing-readiness';
+import { createScannerUnifiedResult } from '../../src/domain/unified-result';
const summaryHeaders = ['Name', 'IP', 'Site', 'Sensor', 'TotalCVEs', 'Critical', 'High', 'Medium', 'Low'];
const detailHeaders = ['Name', 'IP', 'Site', 'Sensor', 'CVE', 'Severity', 'NULL', 'Beschreibung'];
@@ -129,7 +130,7 @@ describe('Microsoft Defender for IoT vulnerability model', () => {
const imported = await importFile(new File([bytes], 'defender-synthetic.xlsx', { type: 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet' }), { profiles: importProfiles });
expect(imported.profileId).toBe('defender-for-iot-vulnerabilities');
- expect(imported.profileVersion).toBe('1.0.0');
+ expect(imported.profileVersion).toBe('1.1.0');
expect(imported.extraction?.extractor).toMatchObject({ id: 'defender-for-iot-vulnerability-source-extractor', version: '1.0.0' });
// Two devices share one CVE: the Work view must show a single aggregated finding, not one row per device.
expect(imported.extraction?.candidates).toHaveLength(1);
@@ -151,13 +152,32 @@ describe('Microsoft Defender for IoT vulnerability model', () => {
detectedTool: { id: 'defender-for-iot-vulnerabilities' },
processedWith: {
profileId: 'defender-for-iot-vulnerabilities',
- profileVersion: '1.0.0',
- compatibilityKey: 'defender-for-iot-vulnerabilities-v1'
+ profileVersion: '1.1.0',
+ normalizationVersion: '1.1.0',
+ compatibilityKey: 'defender-for-iot-vulnerabilities-v2'
}
});
expect(summarizeScanProcessingReadiness(canonical.importFiles)).toMatchObject({ state: 'ready', statuses: ['current'] });
expect(canonical.findingDefinitions).toHaveLength(1);
expect(canonical.findingOccurrences).toHaveLength(1);
+ expect(canonical.findingOccurrences[0]).toMatchObject({
+ outcome: { normalizedValue: 'warning' },
+ technicalExecutionState: { normalizedValue: 'completed' }
+ });
+ expect(createScannerUnifiedResult({
+ project: canonical.project,
+ assessment: canonical.assessment,
+ scanRun: canonical.scanRuns[0],
+ importFile: canonical.importFiles[0],
+ definition: canonical.findingDefinitions[0],
+ occurrence: canonical.findingOccurrences[0],
+ reviews: canonical.reviews
+ })).toMatchObject({
+ resultType: 'vulnerability_finding',
+ outcomeNormalized: 'warning',
+ isIoe: false,
+ isDeviation: true
+ });
// The aggregated CVE carries its affected-device count as the affected asset (two devices here); the device list lives in the evidence table.
expect(canonical.findingOccurrences[0].affectedAsset?.normalizedValue).toBe('2');
expect(canonical.findingOccurrences[0].score).toBeUndefined();
diff --git a/tests/postgres/vulnerability-finding-schema.test.ts b/tests/postgres/vulnerability-finding-schema.test.ts
new file mode 100644
index 0000000..9079f94
--- /dev/null
+++ b/tests/postgres/vulnerability-finding-schema.test.ts
@@ -0,0 +1,30 @@
+import { readFile } from 'node:fs/promises';
+import { resolve } from 'node:path';
+import { describe, expect, it } from 'vitest';
+import { databaseMigrations } from '../../server/postgres/migration-catalog';
+
+const migrationPath = resolve(
+ import.meta.dirname,
+ '..',
+ '..',
+ 'server',
+ 'postgres',
+ 'migrations',
+ '022_vulnerability_finding_result_type.sql'
+);
+
+describe('PostgreSQL vulnerability finding result type migration', () => {
+ it('registers migration 022 after CVE enrichment', () => {
+ expect(databaseMigrations.at(-1)).toMatchObject({
+ version: '022',
+ name: 'vulnerability-finding-result-type'
+ });
+ });
+
+ it('extends the closed result type constraint without rewriting occurrences', async () => {
+ const sql = await readFile(migrationPath, 'utf8');
+ expect(sql).toContain("'vulnerability_finding'");
+ expect(sql).toContain('assessor_occurrences_result_type_check');
+ expect(sql).not.toMatch(/UPDATE\s+assessor_finding_occurrences/i);
+ });
+});
diff --git a/tests/profiles/declarative-profiles.test.ts b/tests/profiles/declarative-profiles.test.ts
index a423ad3..52f28a8 100644
--- a/tests/profiles/declarative-profiles.test.ts
+++ b/tests/profiles/declarative-profiles.test.ts
@@ -115,6 +115,14 @@ describe('declarative tool profiles', () => {
expect(profile?.matchesStatus(imported.sheets[0].analysis.records[0], 'deviation')).toBe(true);
});
+ it('uses the canonical missing-status warning for Defender CVEs in Work', () => {
+ const profile = importProfiles.find(candidate => candidate.id === 'defender-for-iot-vulnerabilities');
+ const fields = [{ label: 'CVE', value: 'CVE-2026-0001', index: 0 }, { label: 'Severity', value: 'Critical', index: 1 }];
+ const record = { id: 'defender-record', index: 0, title: 'CVE-2026-0001', fields, filled: fields, meta: [] };
+
+ expect(profile?.matchesStatus(record, 'deviation')).toBe(true);
+ });
+
it('requires confirmation and keeps the generic profile when only the file name identifies a tool', async () => {
const imported = await importFile(new File(['Alpha;Beta\none;two'], 'CIS-CAT-SYNTHETIC.csv', { type: 'text/csv' }), options);
--
2.39.5
From 33d20193a5127c4784f220c60cd204205056cb24 Mon Sep 17 00:00:00 2001
From: Binh
Date: Fri, 11 Sep 2026 10:29:25 +0200
Subject: [PATCH 05/33] feat(defender-for-iot): add vulnerability finding
result type and backfill logic
---
docs/CANONICAL_MODEL.md | 14 ++++++++++
docs/IMPLEMENTATION_PLAN.md | 3 +++
server/postgres/migration-catalog.ts | 4 ++-
.../023_defender_vulnerability_backfill.sql | 12 +++++++++
src/domain/canonical-model.ts | 6 ++---
src/domain/unified-result.ts | 13 +++++++--
tests/importers/defender-for-iot.test.ts | 17 ++++++++++++
.../vulnerability-finding-schema.test.ts | 27 ++++++++++++++++---
8 files changed, 87 insertions(+), 9 deletions(-)
create mode 100644 server/postgres/migrations/023_defender_vulnerability_backfill.sql
diff --git a/docs/CANONICAL_MODEL.md b/docs/CANONICAL_MODEL.md
index 8922035..dc40d3f 100644
--- a/docs/CANONICAL_MODEL.md
+++ b/docs/CANONICAL_MODEL.md
@@ -95,3 +95,17 @@ Haupttabelle. Der unveränderte externe Vertragstext liegt unter
und ihre Begründung stehen in
[`RESULT_CONTRACT.md`](RESULT_CONTRACT.md#abweichungen-der-assessor-realisierung).
Dieses Dokument bleibt der fachlich verbindliche, implementierte Stand.
+
+### ASSESSOR-Erweiterung: Vulnerability Finding
+
+Seit 2026-09-11 erweitert ASSESSOR den geschlossenen externen
+`result_type`-Katalog additiv um `vulnerability_finding`. Der Typ bezeichnet
+einen Scannerbefund zu einer konkreten Schwachstelle, ohne ihn als bestaetigten
+Indicator of Exposure zu klassifizieren. Microsoft-Defender-for-IoT-CVEs werden
+als `vulnerability_finding` mit `outcome = warning`, `is_ioe = false` und damit
+`is_deviation = true` projiziert. Severity bleibt eine unabhaengige Achse.
+
+`environment-observation` bleibt dagegen ein `source_kind`, kein weiterer
+`result_type`; diese Kontext- und Inventardaten werden als `informational`
+projiziert. Der unveraenderte externe Referenzvertrag 1.0.0 wird durch diese
+ASSESSOR-spezifische Erweiterung nicht rueckwirkend umgeschrieben.
diff --git a/docs/IMPLEMENTATION_PLAN.md b/docs/IMPLEMENTATION_PLAN.md
index 514a0fa..1c6aed0 100644
--- a/docs/IMPLEMENTATION_PLAN.md
+++ b/docs/IMPLEMENTATION_PLAN.md
@@ -1371,6 +1371,7 @@ Aktualisierung nach dem Schritt-11-Orchestrierungsvertikalschnitt vom 2026-08-04
| Datum | Entscheidung | Begründung |
|---|---|---|
+| 2026-09-11 | ASSESSOR erweitert den unveraenderten externen `result_type`-Katalog additiv um `vulnerability_finding`. Defender-for-IoT-CVEs erhalten bei fehlendem Quellstatus deklarativ `outcome=warning`; sie sind damit Abweichungen, bleiben aber `is_ioe=false`. `environment-observation` bleibt eine Herkunftsart mit `result_type=informational`. | Eine konkrete CVE auf betroffenen Devices ist weder Compliance-Check noch Policy-Abweichung oder blosse Inventarinformation. `exposure_finding` wuerde die vorhandene Exposure-State-/IOE-Semantik unnoetig auf Schwachstellen ausdehnen. Der eigene Typ trennt Schwachstellenbefund, Dringlichkeit und bestaetigte Exposure weiterhin sauber. |
| 2026-09-10 | NVD `configurations` bleiben als top-level Konfigurationsgruppen erhalten. Vulnerable CPE-Matches bilden die betroffene Software je Gruppe; nicht vulnerable Matches derselben Gruppe werden getrennt als `Running on/with` gespeichert und dargestellt. Das Enrichment-Recordformat ist dafuer Version 2; Version-1-Flachsaetze bleiben lesbar, muessen fuer die verlustfreie Gruppierung aber erneut von NVD abgerufen werden. | Die NVD-Oberflaeche und API beschreiben eine logische Konfiguration aus betroffener Software und ihren Laufzeit-/Hardwarebedingungen. Ein flaches Match-Array ueberzaehlt Konfigurationen und verliert genau diese Beziehung. Die Gruppierung muss deshalb vor der Persistenz im externen Referenzadapter erhalten werden. |
| 2026-09-10 | CVE-Enrichment ist ein globaler, nach normalisierter CVE-ID identifizierter Referenzbestand und weder Bestandteil der tenant-/timeslotgebundenen FindingOccurrence noch der werkzeuggebundenen, durch Reimport ersetzbaren FindingDefinition. Defender-Import und NVD-Enrichment bleiben getrennt; nur eine ausdrueckliche Aktion fuer eine bereits gespeicherte Defender-CVE darf den festen NVD-Endpunkt abfragen. | Beschreibung, CVSS-Metriken, CWE, Referenzen und betroffene Konfigurationen beschreiben die CVE selbst. Ein gemeinsamer Datensatz vermeidet redundante, auseinanderlaufende Kopien und macht vorhandene Anreicherung fuer spaetere Mandanten automatisch wiederverwendbar, waehrend der Import ohne Netzabhaengigkeit reproduzierbar bleibt. |
| 2026-08-25 | Die appweite persistente Markierungs- und Auswahlfarbe ist auf ausdrueckliche Nutzerfestlegung immer Gelb und wird in beiden Themes ueber `--marking-color` gefuehrt. Kachelauswahl, Auswahlrahmen/-marker, gemerkte Eintraege und Graphauswahl verwenden diesen Token. Blau bleibt Tastaturfokus; Gruen, Rot, Orange und Severitytoene bleiben fachliche Statussignale. | Ein einzelner semantischer Markierungston verhindert violette oder skinabhaengig wechselnde Auswahlkonturen wie im Datahub-Screenshot und bewahrt gleichzeitig die Bedeutung bestehender Statusfarben. |
@@ -1641,6 +1642,7 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode
| Risiko | Gegenmaßnahme |
|---|---|
+| Alte Defender-Importe mit Profil 1.0.0 tragen im gespeicherten Occurrence-JSON weiterhin `outcome=unknown`; wenn Work bereits die aktuelle Profilregel verwendet, koennten Projektion und SQL-Vorfilterung widerspruechlich werden. | Profil 1.1.0 als semantisch inkompatiblen Vertrag mit neuem Compatibility Key registrieren. Die unveraenderliche Migration 022 erweitert den Result-Type-Constraint; Migration 023 zieht ausschliesslich die abgeleiteten relationalen Read-Model-Spalten `result_type` und `outcome_normalized` fuer bestehende Defender-Vorkommen nach. Originalfelder, Occurrence-JSON und Profilprovenienz bleiben unveraendert. Die Leseprojektion behandelt einen nachweislich statuslosen historischen Vulnerability-Fund ebenso. Reimport/Reprocessing bleibt fuer einen vollstaendig aktuellen kanonischen Datensatz erforderlich. |
| NVD kann nicht erreichbar oder rate-limitiert sein, unerwartet grosse Antworten liefern oder externe Referenz-URLs enthalten; ein API-Schluessel darf nicht an Browser oder Logs gelangen. Eine automatische Anreicherung waehrend des Imports wuerde zudem dessen Reproduzierbarkeit und Verfuegbarkeit an einen externen Dienst koppeln. | Enrichment ausschliesslich separat und nutzerausgeloest im Backend ausfuehren, nur exakt gespeicherte Defender-CVE-IDs akzeptieren, Zielorigin und API-Pfad fest verdrahten sowie Timeout und 8-MiB-Antwortgrenze erzwingen. Den optionalen Schluessel nur aus `NVD_API_KEY` als Serverheader senden, Antwortfelder normalisieren, Referenzen nur als HTTP(S)-Links darstellen und Importfehler strikt vom Enrichment-Ergebnis trennen. |
| Defender-for-IoT-Summarys koennen Severity-Zahlen ohne einzelne CVEs enthalten; wiederholte Sensorzeilen koennen dieselbe Device-CVE-Beziehung mehrfach melden, und pseudonymisierte oder wiederverwendete Adressen koennen Identitaeten mehrdeutig machen. | Aggregate ohne Detail niemals in Findings umwandeln, Device-mal-CVE vor der kanonischen Projektion deduplizieren, alle Sensorzeilen als Evidenz erhalten, Identitaet nach der dokumentierten MAC-/IP-/Name-Site-Reihenfolge bilden und Konflikte beziehungsweise Reconciliation-Abweichungen diagnostizieren statt still zusammenzufuehren. |
| Ein gemischtes All-Records-Blatt kann den generischen Titel `Name` auf alle Scanner anwenden und dadurch bei Defender die Device-IP statt der CVE anzeigen; zugleich kann eine rein profilgebundene Client-Info-Sonderansicht in gemischten Timeslots verschwinden. | Titel im gemischten Blatt je Datensatz aus dessen `Source: Scan`-Provenienz und deklarativem Werkzeugprofil bestimmen. Die allgemeine Client-Info-Uebersicht beibehalten und die Defender-Projektion bei vorhandenen Defender-Quellblaettern als eigenen Tab anbieten. |
@@ -1835,6 +1837,7 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode
## 12. Änderungsprotokoll
| Datum | Änderung |
+| 2026-09-11 | Phasen 2/6/7/11 um den eigenen Schwachstellen-Ergebnistyp erweitert: `vulnerability_finding` ist eine additive ASSESSOR-Erweiterung des unveraenderten externen Result Contract 1.0.0. Das Defender-Profil 1.1.0 setzt fuer statuslose CVE-Findings deklarativ `outcome=warning`; Work und Unified Result projizieren dadurch `result_type=vulnerability_finding`, `is_ioe=false` und `deviation=true`. Die bereits angewandte Migration 022 bleibt checksum-identisch und erweitert nur den geschlossenen PostgreSQL-Constraint; die nachtraeglich benoetigte Aktualisierung bestehender abgeleiteter Result-Type-/Outcome-Spalten liegt append-only in Migration 023. Originalfelder, Occurrence-JSON und Profilprovenienz bleiben unveraendert. Profil 1.0.0 bleibt wegen der geaenderten kanonischen Semantik inkompatibel und benoetigt fuer einen vollstaendig aktuellen Datensatz Reimport/Reprocessing. 787 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Phasen 2, 6, 7 und 11 bleiben abgeschlossen. |
| 2026-09-11 | Phase-7-Abweichungsfilter zwischen Work und Result DB vereinheitlicht: Work prueft `deviation` nicht mehr gegen beliebige profilbezogene Rohwertmuster wie Defender-Severity `Critical`, sondern rekonstruiert aus Werkzeug und Statusfeld dieselben kanonischen Achsen Outcome, Result Type, Exposure State und `is_ioe` und verwendet anschliessend das gemeinsame versionierte Abweichungspraedikat. Defender-CVEs ohne Status bleiben damit wie in der Result DB `outcome=unknown`, `is_ioe=false`, `deviation=false`; Fail-/Warning-Ergebnisse und festgestellte Expositionen bleiben Abweichungen. Keine Daten-, API-, Schema-, Persistenz- oder Profilversionsaenderung. 781 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Phase 7 bleibt abgeschlossen. |
| 2026-09-10 | Result-DB-Beschreibungsdeduplizierung fuer einzelne Defender-CVEs nachgehaertet: Scanner- und NVD-Beschreibung werden fuer den reinen Anzeigevergleich jetzt Unicode-NFKC-normalisiert, von unsichtbaren Formatzeichen bereinigt, case-insensitiv behandelt und ueber ihre Wort-/Zahlfolge verglichen. Dadurch werden visuell identische Saetze auch bei Soft-Hyphen-, Zeichensetzungs- oder Grossschreibungsabweichungen nicht doppelt gerendert; inhaltlich unterschiedliche Wortfolgen bleiben sichtbar. Gespeicherte Quelltexte bleiben unveraendert. Drei fokussierte Regressionstests und der Client-Produktionsbuild sind erfolgreich. |
| 2026-09-10 | Work-Darstellung der gruppierten NVD-Konfigurationen an die Originalstruktur angenaehert: Jede nummerierte `Configuration` rendert genau eine Tabelle. Nach den betroffenen CPE-Zeilen steht `Running on/with` als eigene Tabellenzeile; die zugeordneten Plattform-CPEs folgen innerhalb derselben Tabelle statt in einer zweiten Tabelle. Gruppierung, Speicherung und Reihenfolge der Findings bleiben unveraendert. 17 fokussierte Finding-/CVE-Darstellungstests und der Client-Produktionsbuild sind erfolgreich. |
diff --git a/server/postgres/migration-catalog.ts b/server/postgres/migration-catalog.ts
index 38ed8f8..8804acf 100644
--- a/server/postgres/migration-catalog.ts
+++ b/server/postgres/migration-catalog.ts
@@ -18,6 +18,7 @@ import policyFindingFactory from './migrations/017_policy_finding_factory.sql?ra
import scannerEnvironmentContext from './migrations/018_scanner_environment_context.sql?raw';
import cveEnrichment from './migrations/021_cve_enrichment.sql?raw';
import vulnerabilityFindingResultType from './migrations/022_vulnerability_finding_result_type.sql?raw';
+import defenderVulnerabilityBackfill from './migrations/023_defender_vulnerability_backfill.sql?raw';
export interface DatabaseMigration {
version: string;
@@ -45,5 +46,6 @@ export const databaseMigrations: readonly DatabaseMigration[] = [
{ version: '017', name: 'policy-finding-factory', sql: policyFindingFactory },
{ version: '018', name: 'scanner-environment-context', sql: scannerEnvironmentContext },
{ version: '021', name: 'cve-enrichment', sql: cveEnrichment },
- { version: '022', name: 'vulnerability-finding-result-type', sql: vulnerabilityFindingResultType }
+ { version: '022', name: 'vulnerability-finding-result-type', sql: vulnerabilityFindingResultType },
+ { version: '023', name: 'defender-vulnerability-backfill', sql: defenderVulnerabilityBackfill }
];
diff --git a/server/postgres/migrations/023_defender_vulnerability_backfill.sql b/server/postgres/migrations/023_defender_vulnerability_backfill.sql
new file mode 100644
index 0000000..e1147b8
--- /dev/null
+++ b/server/postgres/migrations/023_defender_vulnerability_backfill.sql
@@ -0,0 +1,12 @@
+-- Backfill ausschliesslich der abgeleiteten, indizierten Read-Model-Spalten
+-- fuer bereits importierte Defender-CVEs. Originalfelder, Occurrence-JSON und
+-- Importprovenienz bleiben unveraendert.
+
+UPDATE assessor_finding_occurrences
+SET
+ result_type = 'vulnerability_finding',
+ outcome_normalized = CASE
+ WHEN outcome_normalized = 'unknown' THEN 'warning'
+ ELSE outcome_normalized
+ END
+WHERE lower(btrim(tool_id)) = 'defender-for-iot-vulnerabilities';
diff --git a/src/domain/canonical-model.ts b/src/domain/canonical-model.ts
index fd64599..772412f 100644
--- a/src/domain/canonical-model.ts
+++ b/src/domain/canonical-model.ts
@@ -6,8 +6,9 @@ export type JsonPrimitive = string | number | boolean | null;
export type JsonValue = JsonPrimitive | JsonValue[] | { [key: string]: JsonValue };
/**
- * result_type aus RESULT_CONTRACT 1.0.0 (docs/RESULT_CONTRACT.md). Additive
- * Facette, ausschließlich über src/domain/result-contract-mapping.ts abgeleitet.
+ * result_type aus RESULT_CONTRACT 1.0.0 plus dokumentierte ASSESSOR-Erweiterungen
+ * (docs/CANONICAL_MODEL.md). Additive Facette, ausschließlich über
+ * src/domain/result-contract-mapping.ts abgeleitet.
*/
export type CanonicalResultType = ResultContractResultType;
@@ -337,4 +338,3 @@ export interface CanonicalAssessmentModel {
reviews: FindingReview[];
diagnostics: ImportDiagnostic[];
}
-
diff --git a/src/domain/unified-result.ts b/src/domain/unified-result.ts
index 61c0199..626fa6f 100644
--- a/src/domain/unified-result.ts
+++ b/src/domain/unified-result.ts
@@ -294,10 +294,19 @@ function mappingConfidence(occurrence: FindingOccurrence): number {
export function createScannerUnifiedResult(source: ScannerUnifiedResultSource): UnifiedResultProjection {
const review = matchingReview(source);
const dimensions = reviewDimensions(review);
- const outcomeNormalized = source.occurrence.outcome?.normalizedValue
- ?? outcomeFromLegacyStatus(source.occurrence.status.normalizedValue ?? 'unknown');
const resultType = source.occurrence.resultType
?? deriveResultType(source.occurrence.sourceIdentity.tool.id);
+ const recordedOutcome = source.occurrence.outcome?.normalizedValue
+ ?? outcomeFromLegacyStatus(source.occurrence.status.normalizedValue ?? 'unknown');
+ const originalOutcome = source.occurrence.outcome?.originalValue ?? source.occurrence.status.originalValue;
+ const hasOriginalOutcome = typeof originalOutcome === 'string'
+ ? Boolean(originalOutcome.trim())
+ : originalOutcome !== null && originalOutcome !== undefined;
+ const outcomeNormalized = resultType === 'vulnerability_finding'
+ && recordedOutcome === 'unknown'
+ && !hasOriginalOutcome
+ ? 'warning'
+ : recordedOutcome;
const exposureState = source.occurrence.exposureState
?? deriveExposureState(resultType, outcomeNormalized);
const isIoe = source.occurrence.isIoe
diff --git a/tests/importers/defender-for-iot.test.ts b/tests/importers/defender-for-iot.test.ts
index 6babc00..7ce6108 100644
--- a/tests/importers/defender-for-iot.test.ts
+++ b/tests/importers/defender-for-iot.test.ts
@@ -178,6 +178,23 @@ describe('Microsoft Defender for IoT vulnerability model', () => {
isIoe: false,
isDeviation: true
});
+ expect(createScannerUnifiedResult({
+ project: canonical.project,
+ assessment: canonical.assessment,
+ scanRun: canonical.scanRuns[0],
+ importFile: canonical.importFiles[0],
+ definition: canonical.findingDefinitions[0],
+ occurrence: {
+ ...canonical.findingOccurrences[0],
+ outcome: { ...canonical.findingOccurrences[0].outcome!, normalizedValue: 'unknown' }
+ },
+ reviews: canonical.reviews
+ })).toMatchObject({
+ resultType: 'vulnerability_finding',
+ outcomeNormalized: 'warning',
+ isIoe: false,
+ isDeviation: true
+ });
// The aggregated CVE carries its affected-device count as the affected asset (two devices here); the device list lives in the evidence table.
expect(canonical.findingOccurrences[0].affectedAsset?.normalizedValue).toBe('2');
expect(canonical.findingOccurrences[0].score).toBeUndefined();
diff --git a/tests/postgres/vulnerability-finding-schema.test.ts b/tests/postgres/vulnerability-finding-schema.test.ts
index 9079f94..2f4af44 100644
--- a/tests/postgres/vulnerability-finding-schema.test.ts
+++ b/tests/postgres/vulnerability-finding-schema.test.ts
@@ -12,19 +12,40 @@ const migrationPath = resolve(
'migrations',
'022_vulnerability_finding_result_type.sql'
);
+const backfillPath = resolve(
+ import.meta.dirname,
+ '..',
+ '..',
+ 'server',
+ 'postgres',
+ 'migrations',
+ '023_defender_vulnerability_backfill.sql'
+);
describe('PostgreSQL vulnerability finding result type migration', () => {
- it('registers migration 022 after CVE enrichment', () => {
- expect(databaseMigrations.at(-1)).toMatchObject({
+ it('registers the immutable catalog extension before the Defender backfill', () => {
+ expect(databaseMigrations.at(-2)).toMatchObject({
version: '022',
name: 'vulnerability-finding-result-type'
});
+ expect(databaseMigrations.at(-1)).toMatchObject({
+ version: '023',
+ name: 'defender-vulnerability-backfill'
+ });
});
- it('extends the closed result type constraint without rewriting occurrences', async () => {
+ it('keeps migration 022 limited to the closed result type constraint', async () => {
const sql = await readFile(migrationPath, 'utf8');
expect(sql).toContain("'vulnerability_finding'");
expect(sql).toContain('assessor_occurrences_result_type_check');
expect(sql).not.toMatch(/UPDATE\s+assessor_finding_occurrences/i);
});
+
+ it('backfills only derived Defender columns in migration 023', async () => {
+ const sql = await readFile(backfillPath, 'utf8');
+ expect(sql).toMatch(/UPDATE\s+assessor_finding_occurrences/i);
+ expect(sql).toContain("outcome_normalized = 'unknown' THEN 'warning'");
+ expect(sql).toContain("lower(btrim(tool_id)) = 'defender-for-iot-vulnerabilities'");
+ expect(sql).not.toMatch(/jsonb_set|\bdata\s*=/i);
+ });
});
--
2.39.5
From f4f5f3dff59871829c3583b1ada7297a03ac4771 Mon Sep 17 00:00:00 2001
From: Michael
Date: Thu, 3 Sep 2026 12:21:37 +0200
Subject: [PATCH 06/33] Implementation + policy Upadets codex
---
docs/IMPLEMENTATION_PLAN.md | 5 +
src/domain/policy-evaluation-rules.ts | 80 ++++++++++--
tests/domain/policy-evaluation-rules.test.ts | 122 +++++++++++++++++++
3 files changed, 200 insertions(+), 7 deletions(-)
create mode 100644 tests/domain/policy-evaluation-rules.test.ts
diff --git a/docs/IMPLEMENTATION_PLAN.md b/docs/IMPLEMENTATION_PLAN.md
index 1c6aed0..2610642 100644
--- a/docs/IMPLEMENTATION_PLAN.md
+++ b/docs/IMPLEMENTATION_PLAN.md
@@ -1198,6 +1198,8 @@ Abnahmekriterien:
Status: in Arbeit
+Aktueller verifizierter Zusatzstatus vom 2026-08-26: Die Freigabegrenze des weiterhin fachlich leeren Policy-Evaluation-Regelkatalogs validiert nun alle Runtime-Enumwerte fuer Auslieferungsmechanismus, Baseline-Disposition, Comparator und Severity, blockiert ueberlappende Selektoren beziehungsweise mehrdeutige Regeln und lehnt widerspruechlich wiederverwendete Risiko- oder Abhaengigkeits-IDs fail-closed ab. Es wurden keine Policyempfehlung und keine Severity erfunden oder freigegeben. Der lokale private Artefaktspeicher wurde vom veralteten fremden Benutzerpfad auf den aktuellen LocalAppData-Pfad ausserhalb des Webroots korrigiert; Backend, App und Speicherroot sind inhaltsfrei technisch erreichbar. Neun neue Katalogregressionen, 25 fokussierte GPO-/Katalogtests, die Gesamtsuite mit 764 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt in Arbeit.
+
Aktueller verifizierter Zusatzstatus vom 2026-08-22: Der globale Microsoft-Security-Baselinekatalog besitzt nun einen bestaetigungspflichtigen Delete-Pfad durch UI, Same-Origin-API, Service sowie Local- und PostgreSQL-Repository. Nur nicht von Policy-Evaluationen referenzierte Pakete duerfen geloescht werden; Klassifikationen und gespeicherte Analysen werden zusammen mit dem Katalogeintrag entfernt, das private Originalobjekt anschliessend best-effort bereinigt. Keine SQL-Migration; Phase 13B bleibt in Arbeit.
Ziele:
@@ -1374,6 +1376,7 @@ Aktualisierung nach dem Schritt-11-Orchestrierungsvertikalschnitt vom 2026-08-04
| 2026-09-11 | ASSESSOR erweitert den unveraenderten externen `result_type`-Katalog additiv um `vulnerability_finding`. Defender-for-IoT-CVEs erhalten bei fehlendem Quellstatus deklarativ `outcome=warning`; sie sind damit Abweichungen, bleiben aber `is_ioe=false`. `environment-observation` bleibt eine Herkunftsart mit `result_type=informational`. | Eine konkrete CVE auf betroffenen Devices ist weder Compliance-Check noch Policy-Abweichung oder blosse Inventarinformation. `exposure_finding` wuerde die vorhandene Exposure-State-/IOE-Semantik unnoetig auf Schwachstellen ausdehnen. Der eigene Typ trennt Schwachstellenbefund, Dringlichkeit und bestaetigte Exposure weiterhin sauber. |
| 2026-09-10 | NVD `configurations` bleiben als top-level Konfigurationsgruppen erhalten. Vulnerable CPE-Matches bilden die betroffene Software je Gruppe; nicht vulnerable Matches derselben Gruppe werden getrennt als `Running on/with` gespeichert und dargestellt. Das Enrichment-Recordformat ist dafuer Version 2; Version-1-Flachsaetze bleiben lesbar, muessen fuer die verlustfreie Gruppierung aber erneut von NVD abgerufen werden. | Die NVD-Oberflaeche und API beschreiben eine logische Konfiguration aus betroffener Software und ihren Laufzeit-/Hardwarebedingungen. Ein flaches Match-Array ueberzaehlt Konfigurationen und verliert genau diese Beziehung. Die Gruppierung muss deshalb vor der Persistenz im externen Referenzadapter erhalten werden. |
| 2026-09-10 | CVE-Enrichment ist ein globaler, nach normalisierter CVE-ID identifizierter Referenzbestand und weder Bestandteil der tenant-/timeslotgebundenen FindingOccurrence noch der werkzeuggebundenen, durch Reimport ersetzbaren FindingDefinition. Defender-Import und NVD-Enrichment bleiben getrennt; nur eine ausdrueckliche Aktion fuer eine bereits gespeicherte Defender-CVE darf den festen NVD-Endpunkt abfragen. | Beschreibung, CVSS-Metriken, CWE, Referenzen und betroffene Konfigurationen beschreiben die CVE selbst. Ein gemeinsamer Datensatz vermeidet redundante, auseinanderlaufende Kopien und macht vorhandene Anreicherung fuer spaetere Mandanten automatisch wiederverwendbar, waehrend der Import ohne Netzabhaengigkeit reproduzierbar bleibt. |
+| 2026-08-26 | Ein Policy-Evaluation-Regelkatalog darf den Status `released` nur tragen, wenn seine Runtime-Vertraege geschlossen validiert sind und fuer dieselbe technische Identitaet, denselben Auslieferungsmechanismus und ueberlappende Produkt-/Versions-/Rollen-/Scope-Kontexte hoechstens eine Regel aufloesbar ist. Wiederverwendete Risiko- und Abhaengigkeits-IDs muessen katalogweit dieselbe Definition besitzen. | Der kuenftige fachlich kuratierte Katalog wird an einer sicherheitsrelevanten Finding-Grenze ausgefuehrt. TypeScript-Typen allein schuetzen weder geladene noch historisch persistierte Runtime-Daten; Mehrdeutigkeit oder unbekannte Enumwerte muessen deshalb vor jeder Freigabe fail-closed blockieren. |
| 2026-08-25 | Die appweite persistente Markierungs- und Auswahlfarbe ist auf ausdrueckliche Nutzerfestlegung immer Gelb und wird in beiden Themes ueber `--marking-color` gefuehrt. Kachelauswahl, Auswahlrahmen/-marker, gemerkte Eintraege und Graphauswahl verwenden diesen Token. Blau bleibt Tastaturfokus; Gruen, Rot, Orange und Severitytoene bleiben fachliche Statussignale. | Ein einzelner semantischer Markierungston verhindert violette oder skinabhaengig wechselnde Auswahlkonturen wie im Datahub-Screenshot und bewahrt gleichzeitig die Bedeutung bestehender Statusfarben. |
| 2026-08-25 | Die unmittelbar zuvor fuer Client Info festgelegte flache SOC-Kachel ist auf ausdrueckliche Nutzerfestlegung der neue appweite Kachelstandard: keine sichtbare Normalzustandskontur, kein Radius und kein Schatten; Hover veraendert nur die Flaeche. Fokus, Auswahl und kleine Statusakzente bleiben funktionale Ausnahmen. Die gemeinsamen `--tile-*`-Tokens und Projektregeln tragen diesen Vertrag. | Ein zentraler Standard verhindert, dass neue oder bestehende Ansichten erneut weisse Konturen, Rundungen oder schwebende Schatten einfuehren. Flaechenkontrast und gemeinsamer Abstand erzeugen die gewuenschte ruhige, dichte SOC-Geometrie. |
| 2026-08-25 | Das quadratische Client-Info-Raster uebernimmt die flache Kartenoberflaeche der Nutzerreferenz: regulaere Kennzahl- und Inhaltskacheln haben keine Aussenkontur, keinen Schatten, den zentralen Nullradius und keine dekorative Trennlinie unter dem Kartentitel. Farbige Fokus- und Auswahlkonturen bleiben als funktionale Zustaende erhalten. | In der Referenz werden Karten allein durch Flaechenkontrast und dunkle Zwischenraeume getrennt. Die bisherige helle Kontur, Rundung und Schattenkante erzeugten eine abweichende, unruhige zweite Geometrieebene. |
@@ -1646,6 +1649,7 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode
| NVD kann nicht erreichbar oder rate-limitiert sein, unerwartet grosse Antworten liefern oder externe Referenz-URLs enthalten; ein API-Schluessel darf nicht an Browser oder Logs gelangen. Eine automatische Anreicherung waehrend des Imports wuerde zudem dessen Reproduzierbarkeit und Verfuegbarkeit an einen externen Dienst koppeln. | Enrichment ausschliesslich separat und nutzerausgeloest im Backend ausfuehren, nur exakt gespeicherte Defender-CVE-IDs akzeptieren, Zielorigin und API-Pfad fest verdrahten sowie Timeout und 8-MiB-Antwortgrenze erzwingen. Den optionalen Schluessel nur aus `NVD_API_KEY` als Serverheader senden, Antwortfelder normalisieren, Referenzen nur als HTTP(S)-Links darstellen und Importfehler strikt vom Enrichment-Ergebnis trennen. |
| Defender-for-IoT-Summarys koennen Severity-Zahlen ohne einzelne CVEs enthalten; wiederholte Sensorzeilen koennen dieselbe Device-CVE-Beziehung mehrfach melden, und pseudonymisierte oder wiederverwendete Adressen koennen Identitaeten mehrdeutig machen. | Aggregate ohne Detail niemals in Findings umwandeln, Device-mal-CVE vor der kanonischen Projektion deduplizieren, alle Sensorzeilen als Evidenz erhalten, Identitaet nach der dokumentierten MAC-/IP-/Name-Site-Reihenfolge bilden und Konflikte beziehungsweise Reconciliation-Abweichungen diagnostizieren statt still zusammenzufuehren. |
| Ein gemischtes All-Records-Blatt kann den generischen Titel `Name` auf alle Scanner anwenden und dadurch bei Defender die Device-IP statt der CVE anzeigen; zugleich kann eine rein profilgebundene Client-Info-Sonderansicht in gemischten Timeslots verschwinden. | Titel im gemischten Blatt je Datensatz aus dessen `Source: Scan`-Provenienz und deklarativem Werkzeugprofil bestimmen. Die allgemeine Client-Info-Uebersicht beibehalten und die Defender-Projektion bei vorhandenen Defender-Quellblaettern als eigenen Tab anbieten. |
+| Ein formal als `released` markierter Policy-Regelkatalog enthaelt unbekannte Runtime-Enumwerte, ueberlappende Kontextselektoren, mehrdeutige Regeln oder widerspruechlich wiederverwendete Risiko-/Abhaengigkeits-IDs und erzeugt dadurch nicht reproduzierbare beziehungsweise fachlich falsche Evaluationen oder Findings. | Die zentrale Katalogvalidierung prueft Auslieferungsmechanismen, Dispositionen, Comparatorvarianten und -modi, Severity, Kontextueberlappung sowie katalogweite ID-Definitionen geschlossen und fail-closed. Jede spaetere fachliche Katalogerweiterung benoetigt positive und negative synthetische Freigaberegressionen; der produktive Katalog bleibt bis zur fachlichen Kuratierung leer. |
| Auswahl, Fokus und fachlicher Status koennen erneut farblich vermischt werden, wenn Komponenten direkt Akzent-, Fokus- oder Severitytokens fuer eine persistente Markierung verwenden. | Persistente Auswahl ausschliesslich an `--marking-color` binden und in beiden Themes auf denselben Gelbwert regressionspruefen. `--focus-ring` bleibt nur fuer Tastaturfokus; Online-, Fehler-, Workflow- und Severityfarben bleiben fachlich getrennt. |
| Einzelansichten koennten trotz flacher gemeinsamer Tokens im Hover erneut dekorative Konturen setzen oder den Standard mit lokalen Radien und Schatten umgehen. | Appweite Projektregel und Regression an die flachen `--tile-*`-Tokens binden; normale und Hover-Zustaende getrennt von Fokus, Auswahl und Statusakzenten pruefen. Lokale Kachelgeometrie bleibt unzulaessig. |
| Kontur- und schattenlose Client-Info-Kacheln koennen bei spaeteren Themeaenderungen ihren Flaechenkontrast zum Dashboardgrund verlieren; interaktive Kacheln koennten ohne eigene Zustandsmarkierung schwer erkennbar werden. | Karten- und Grundflaeche ueber die bestehenden Theme-Tokens getrennt halten, Hover weiterhin ueber die Hoverflaeche zeigen und Fokus sowie Auswahl mit den vorhandenen farbigen Konturen sichern. Die Dashboardregression prueft den flachen Normalzustand getrennt von diesen Funktionszustaenden. |
@@ -1853,6 +1857,7 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode
| 2026-09-10 | Phasen 7/13A fuer gemischte Defender-Timeslots korrigiert: Work bestimmt den Titel jedes Datensatzes anhand seiner Scannerprovenienz und des deklarativen Titel-Headers, sodass Defender-Vorkommen im gemeinsamen All-Records-Blatt die CVE statt Device-Name oder IP zeigen. Client Info behaelt bei mehreren Scannern die allgemeine Uebersicht und bietet Defender zusaetzlich als eigenen Tab mit den vorhandenen CVE-, Device- und Site-Sichten an. 19 fokussierte Dashboard-, Titel- und Graphregressionen erfolgreich. Keine API-, SQL-, Profil- oder Persistenzmigration; Phasen 7 und 13A bleiben abgeschlossen. |
| 2026-09-10 | Phase-13A-Verarbeitungsvertrag fuer Defender-Importe korrigiert: Die Kompatibilitaetspruefung verwendet nun den tatsaechlich persistierten `processedWith.profileId` statt einer eventuell abweichenden erkannten Werkzeug-ID. Dadurch werden registrierte Defender-Profile 1.0.0 als aktuell bewertet; unbekannte Profil-/Versionspaare bleiben fail closed. Die Korrektur ist read-only fuer vorhandene Importdaten und benoetigt keinen Reimport oder Datenbankeingriff. 17 fokussierte Import-/Kompatibilitaetstests sowie der Gesamtlauf mit 766 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich; Phase 13A bleibt abgeschlossen. |
| 2026-09-10 | Microsoft Defender for IoT vulnerability imports and views umgesetzt: Profil und Source Extractor 1.0.0 erweitern die generische Excel-/CSV-Pipeline; Device-Identitaeten, CVE-Definitionen, Device-mal-CVE-Vorkommen, rohe Sensorbeobachtungen und Aggregate-only-Zahlen bleiben getrennt. Client Info bietet CVE-, Device- und Site-Sichten mit Evidenz- und Reconciliation-Drill-down. Summary-only-Quellen bleiben ohne erfundene Findings viewable. 33 fokussierte synthetische Tests sowie 764 Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL- oder Persistenzmigration; Phasen 6, 7 und 13A bleiben abgeschlossen. |
+| 2026-08-26 | Phase-13B-Regelkatalog-Freigabegrenze gehaertet: Runtimevalidierung fuer geschlossene Auslieferungsmechanismen, Baseline-Dispositionen, Comparatorvarianten/-modi und Severitywerte ergaenzt; ueberlappende Selektoren, mehrdeutige kontextspezifische Regeln sowie widerspruechliche Risiko- und Abhaengigkeitsdefinitionen werden vor Serviceaktivierung fail-closed abgelehnt. Der fachliche Produktivkatalog bleibt bewusst leer. Der lokale private Artefaktspeicher zeigt wieder auf den aktuellen LocalAppData-Pfad ausserhalb des Webroots; Backend `ok`, App HTTP 200 und vorhandener Speicherroot wurden ohne Inhaltszugriff bestaetigt. Neun neue synthetische Katalogtests, 25 fokussierte GPO-/Katalogtests, 764 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt in Arbeit. |
| 2026-08-25 | Phase-7-Markierungsfarbe appweit auf Gelb vereinheitlicht: Der neue Theme-Token `--marking-color` traegt in Dark und Light denselben Wert und steuert Kachelauswahl, allgemeine Auswahlrahmen/-marker, gemerkte Eintraege und Graphauswahl. Die violette Datahub-Auswahlkontur entfaellt. Tastaturfokus bleibt blau, Scanner-/Workflow-/Severitystatus behalten ihre fachlichen Farben. Projektregel und Kachelregression wurden aktualisiert. 24 fokussierte Auswahl-/Dashboard-/Graphtests, Designcheck und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Kachelstandard appweit auf die freigegebene flache Client-Info-Geometrie umgestellt: `--tile-border` ist in beiden Themes transparent, `--tile-radius` verwendet den zentralen Nullradius und `--tile-card-shadow` ist deaktiviert. Datahub-, Dashboard-, Sidebar-, Work- und Pathfinder-Hover veraendern die Flaeche ohne dekorative Kontur; Fokus, Auswahl und Statusmarkierungen bleiben sichtbar. `AGENTS.md` und die gemeinsamen Kachelregressionen wurden auf den neuen verbindlichen Standard aktualisiert. 24 fokussierte Kachel-/Dashboardtests, Designcheck und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Client-Info-Kacheldesign nach erneutem Referenzabgleich korrigiert: Die quadratischen Kennzahl- und Inhaltskacheln verwenden im Normalzustand keine helle Aussenkontur, keinen Kartenschatten und keine Rundung; auch die dekorative Linie unter Inhaltskartentiteln entfaellt. Flaechenkontrast und gemeinsamer Rasterabstand trennen die Kacheln wie im Sollbild, waehrend Hover, Tastaturfokus und aktive Filter funktional sichtbar bleiben. Neun fokussierte Dashboardtests, Designcheck und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
diff --git a/src/domain/policy-evaluation-rules.ts b/src/domain/policy-evaluation-rules.ts
index 69cf8a1..640fe2b 100644
--- a/src/domain/policy-evaluation-rules.ts
+++ b/src/domain/policy-evaluation-rules.ts
@@ -74,13 +74,50 @@ function unique(values: string[]): boolean {
return new Set(values).size === values.length && values.every(validText);
}
+const deliveryMechanisms = new Set([
+ 'registry-policy',
+ 'security-template',
+ 'advanced-audit-policy',
+ 'group-policy-preference'
+]);
+
+const baselineDispositions = new Set([
+ 'explicit-recommendation',
+ 'explicitly-not-applicable',
+ 'no-recommendation'
+]);
+
+const riskSeverities = new Set([
+ 'info', 'low', 'medium', 'high', 'critical'
+]);
+
function comparatorIsValid(comparator: PolicyComparatorDefinition | undefined): boolean {
- if (!comparator) return false;
+ if (!comparator || typeof comparator !== 'object') return false;
if (comparator.kind === 'enum') {
- return comparator.orderedValues.length > 0 && comparator.orderedValues.length <= 256
- && unique(comparator.orderedValues);
+ return Array.isArray(comparator.orderedValues) && comparator.orderedValues.length > 0
+ && comparator.orderedValues.length <= 256 && unique(comparator.orderedValues)
+ && ['higher-is-stronger', 'lower-is-stronger'].includes(comparator.direction);
}
- return true;
+ if (comparator.kind === 'bitmask' || comparator.kind === 'audit-flags') {
+ return ['contains-baseline', 'exact'].includes(comparator.mode);
+ }
+ if (comparator.kind === 'set') return ['superset', 'subset', 'exact'].includes(comparator.mode);
+ return ['equality', 'minimum', 'maximum'].includes(comparator.kind);
+}
+
+function selectorsOverlap(left: PolicyEvaluationContextSelector, right: PolicyEvaluationContextSelector): boolean {
+ if (normalized(left.productFamily) !== normalized(right.productFamily)
+ || normalized(left.productVersion) !== normalized(right.productVersion)
+ || !left.scopes.some(scope => right.scopes.includes(scope))) return false;
+ const leftRoles = left.roles.map(normalized);
+ const rightRoles = right.roles.map(normalized);
+ return leftRoles.includes('any') || rightRoles.includes('any')
+ || leftRoles.some(role => rightRoles.includes(role));
+}
+
+function rulesOverlap(left: PolicyEvaluationRule, right: PolicyEvaluationRule): boolean {
+ return left.identityId === right.identityId && left.deliveryMechanism === right.deliveryMechanism
+ && left.contexts.some(leftContext => right.contexts.some(rightContext => selectorsOverlap(leftContext, rightContext)));
}
export function policyEvaluationRuleCatalogValidationErrors(catalog: PolicyEvaluationRuleCatalog): string[] {
@@ -91,16 +128,25 @@ export function policyEvaluationRuleCatalogValidationErrors(catalog: PolicyEvalu
errors.push('Der Policy-Evaluation-Regelkatalog besitzt ungueltige Identitaet oder Provenienz.');
}
const ruleIds = new Set();
+ const dependencyDefinitions = new Map();
+ const riskDefinitions = new Map();
for (const rule of catalog.rules) {
if (rule.version !== 1 || !validText(rule.id) || ruleIds.has(rule.id) || !validText(rule.identityId)
- || !rule.contexts.length || !Array.isArray(rule.dependencies)) {
+ || !deliveryMechanisms.has(rule.deliveryMechanism) || !baselineDispositions.has(rule.baselineDisposition)
+ || !Array.isArray(rule.contexts) || !rule.contexts.length || !Array.isArray(rule.dependencies)) {
errors.push('Der Policy-Evaluation-Regelkatalog enthaelt eine ungueltige oder doppelte Regel.');
}
ruleIds.add(rule.id);
if (rule.baselineDisposition === 'explicit-recommendation') {
if (!comparatorIsValid(rule.comparator) || !rule.riskRule || rule.riskRule.version !== 1
- || !validText(rule.riskRule.id)) {
+ || !validText(rule.riskRule.id) || !riskSeverities.has(rule.riskRule.severity)) {
errors.push('Eine ausdrueckliche Baselineempfehlung benoetigt Comparator und Risikoregel.');
+ } else {
+ const previousSeverity = riskDefinitions.get(rule.riskRule.id);
+ if (previousSeverity && previousSeverity !== rule.riskRule.severity) {
+ errors.push('Eine Risikoregel besitzt widerspruechliche Definitionen.');
+ }
+ riskDefinitions.set(rule.riskRule.id, rule.riskRule.severity);
}
} else if (rule.comparator || rule.riskRule) {
errors.push('Nichtempfehlungen duerfen weder Comparator noch Risikoregel tragen.');
@@ -113,14 +159,34 @@ export function policyEvaluationRuleCatalogValidationErrors(catalog: PolicyEvalu
errors.push('Eine Policy-Evaluation-Regel besitzt einen ungueltigen Kontextselektor.');
}
}
+ for (let left = 0; left < rule.contexts.length; left += 1) {
+ for (let right = left + 1; right < rule.contexts.length; right += 1) {
+ if (selectorsOverlap(rule.contexts[left], rule.contexts[right])) {
+ errors.push('Eine Policy-Evaluation-Regel besitzt ueberlappende Kontextselektoren.');
+ }
+ }
+ }
const dependencyIds = new Set();
for (const dependency of rule.dependencies) {
if (dependency.version !== 1 || !validText(dependency.id) || dependencyIds.has(dependency.id)
- || !validText(dependency.identityId)
+ || !validText(dependency.identityId) || !deliveryMechanisms.has(dependency.deliveryMechanism)
|| !['prerequisite', 'mutual-exclusion', 'override'].includes(dependency.kind)) {
errors.push('Eine Policy-Evaluation-Regel besitzt eine ungueltige oder doppelte Abhaengigkeit.');
}
dependencyIds.add(dependency.id);
+ const definition = [dependency.kind, dependency.identityId, dependency.deliveryMechanism].join('\u0000');
+ const previousDefinition = dependencyDefinitions.get(dependency.id);
+ if (previousDefinition && previousDefinition !== definition) {
+ errors.push('Eine Abhaengigkeitsregel besitzt widerspruechliche Definitionen.');
+ }
+ dependencyDefinitions.set(dependency.id, definition);
+ }
+ }
+ for (let left = 0; left < catalog.rules.length; left += 1) {
+ for (let right = left + 1; right < catalog.rules.length; right += 1) {
+ if (rulesOverlap(catalog.rules[left], catalog.rules[right])) {
+ errors.push('Der freigegebene Policy-Evaluation-Regelkatalog enthaelt mehrdeutige Kontextregeln.');
+ }
}
}
return [...new Set(errors)];
diff --git a/tests/domain/policy-evaluation-rules.test.ts b/tests/domain/policy-evaluation-rules.test.ts
new file mode 100644
index 0000000..296194f
--- /dev/null
+++ b/tests/domain/policy-evaluation-rules.test.ts
@@ -0,0 +1,122 @@
+import { describe, expect, it } from 'vitest';
+import {
+ POLICY_EVALUATION_RULE_CATALOG,
+ policyEvaluationRuleCatalogValidationErrors,
+ type PolicyEvaluationRule,
+ type PolicyEvaluationRuleCatalog
+} from '../../src/domain/policy-evaluation-rules';
+
+function rule(overrides: Partial = {}): PolicyEvaluationRule {
+ return {
+ version: 1,
+ id: 'synthetic-rule',
+ identityId: 'synthetic-identity',
+ deliveryMechanism: 'registry-policy',
+ contexts: [{
+ version: 1,
+ productFamily: 'Windows Server',
+ productVersion: '2022',
+ roles: ['Member Server'],
+ scopes: ['computer']
+ }],
+ baselineDisposition: 'explicit-recommendation',
+ comparator: { kind: 'equality' },
+ riskRule: { version: 1, id: 'synthetic-risk', severity: 'medium' },
+ dependencies: [],
+ ...overrides
+ };
+}
+
+function catalog(rules: PolicyEvaluationRule[]): PolicyEvaluationRuleCatalog {
+ return {
+ version: 1,
+ id: 'synthetic-released-catalog',
+ catalog: POLICY_EVALUATION_RULE_CATALOG,
+ status: 'released',
+ rules
+ };
+}
+
+describe('policy evaluation rule catalog release validation', () => {
+ it('accepts distinct, fully typed released rules', () => {
+ expect(policyEvaluationRuleCatalogValidationErrors(catalog([
+ rule(),
+ rule({
+ id: 'domain-controller-rule',
+ contexts: [{
+ version: 1,
+ productFamily: 'Windows Server',
+ productVersion: '2022',
+ roles: ['Domain Controller'],
+ scopes: ['computer']
+ }]
+ })
+ ]))).toEqual([]);
+ });
+
+ it.each([
+ [{ kind: 'enum', orderedValues: ['on'], direction: 'sideways' }],
+ [{ kind: 'bitmask', mode: 'contains-any' }],
+ [{ kind: 'set', mode: 'overlap' }],
+ [{ kind: 'audit-flags', mode: 'subset' }],
+ [{ kind: 'invented' }]
+ ])('rejects an unsupported comparator contract', (comparator) => {
+ const errors = policyEvaluationRuleCatalogValidationErrors(catalog([
+ rule({ comparator: comparator as PolicyEvaluationRule['comparator'] })
+ ]));
+ expect(errors).toContain('Eine ausdrueckliche Baselineempfehlung benoetigt Comparator und Risikoregel.');
+ });
+
+ it('rejects unsupported runtime enum values at the release boundary', () => {
+ const invalid = rule({
+ deliveryMechanism: 'invented' as PolicyEvaluationRule['deliveryMechanism'],
+ riskRule: { version: 1, id: 'synthetic-risk', severity: 'urgent' as 'medium' }
+ });
+ const errors = policyEvaluationRuleCatalogValidationErrors(catalog([invalid]));
+ expect(errors).toEqual(expect.arrayContaining([
+ 'Der Policy-Evaluation-Regelkatalog enthaelt eine ungueltige oder doppelte Regel.',
+ 'Eine ausdrueckliche Baselineempfehlung benoetigt Comparator und Risikoregel.'
+ ]));
+ });
+
+ it('rejects selectors and separate rules that can match the same context', () => {
+ const overlappingContext = {
+ version: 1 as const,
+ productFamily: 'windows-server',
+ productVersion: '2022',
+ roles: ['any'],
+ scopes: ['computer'] as Array<'computer' | 'user'>
+ };
+ const errors = policyEvaluationRuleCatalogValidationErrors(catalog([
+ rule({ contexts: [rule().contexts[0], overlappingContext] }),
+ rule({ id: 'ambiguous-rule', contexts: [overlappingContext] })
+ ]));
+ expect(errors).toEqual(expect.arrayContaining([
+ 'Eine Policy-Evaluation-Regel besitzt ueberlappende Kontextselektoren.',
+ 'Der freigegebene Policy-Evaluation-Regelkatalog enthaelt mehrdeutige Kontextregeln.'
+ ]));
+ });
+
+ it('rejects conflicting reusable risk and dependency definitions', () => {
+ const dependency = {
+ version: 1 as const,
+ id: 'shared-dependency',
+ identityId: 'dependency-target',
+ deliveryMechanism: 'registry-policy' as const,
+ kind: 'prerequisite' as const
+ };
+ const errors = policyEvaluationRuleCatalogValidationErrors(catalog([
+ rule({ dependencies: [dependency] }),
+ rule({
+ id: 'separate-context-rule',
+ contexts: [{ ...rule().contexts[0], roles: ['Domain Controller'] }],
+ riskRule: { version: 1, id: 'synthetic-risk', severity: 'high' },
+ dependencies: [{ ...dependency, kind: 'override' }]
+ })
+ ]));
+ expect(errors).toEqual(expect.arrayContaining([
+ 'Eine Risikoregel besitzt widerspruechliche Definitionen.',
+ 'Eine Abhaengigkeitsregel besitzt widerspruechliche Definitionen.'
+ ]));
+ });
+});
--
2.39.5
From 4cdf54967dc98548a51b884e75fd372ecc1fe454 Mon Sep 17 00:00:00 2001
From: Michael
Date: Thu, 3 Sep 2026 17:21:17 +0200
Subject: [PATCH 07/33] Client Info Anpassung + weiter GPO Implementierung
---
docs/IMPLEMENTATION_PLAN.md | 116 ++++++++-
docs/LOCAL_BACKEND.md | 20 ++
docs/architecture/gpo-threat-model.md | 1 +
server/assessor-http-server.ts | 1 +
.../policy-evaluation-rule-catalog-loader.ts | 87 +++++++
server/gpo/zip-inventory.ts | 2 +-
server/index.ts | 9 +-
.../postgres/postgres-assessor-repository.ts | 31 ++-
src/app/App.tsx | 20 +-
src/app/AppProvider.tsx | 14 +-
src/components/TileCard/TileCard.tsx | 13 +-
src/domain/policy-analysis-overview.ts | 186 +++++++++++----
src/domain/unified-result.ts | 185 ++++++++++++++-
src/exports/unified-result-jsonl.ts | 72 ++++++
src/features/dashboard/DashboardPanel.tsx | 180 +++++++++-----
src/features/dataset-viewer/DatasetViewer.tsx | 8 +-
src/features/linked-results/LinkedResults.tsx | 28 ++-
src/features/linked-results/maester-error.ts | 69 ++++++
src/features/linked-results/result-message.ts | 10 +-
src/features/project-import/DataHub.tsx | 84 ++++++-
.../project-import/GpoFolderImport.tsx | 69 ++++--
.../project-import/PolicyAnalysisPanel.tsx | 25 +-
.../load-canonical-project-workspace.ts | 20 +-
.../policy-observations-to-dataset.ts | 90 +++++++
.../results-browser/ResultsBrowser.tsx | 66 +++++-
.../results-browser/ResultsFilterPanel.tsx | 5 +-
src/persistence/local-assessor-repository.ts | 9 +-
src/styles/components.css | 13 ++
src/styles/datahub.css | 220 +++++++++++-------
src/styles/legacy-views.css | 15 +-
src/styles/ui-tokens.css | 3 +-
tests/domain/gpo-unified-result.test.ts | 145 ++++++++++++
tests/domain/policy-analysis-overview.test.ts | 102 ++++++++
tests/exports/unified-result-jsonl.test.ts | 87 +++++++
tests/features/dashboard-layout.test.ts | 73 +++++-
.../dashboard-progressive-disclosure.test.tsx | 60 +++++
tests/features/datahub-client-open.test.ts | 7 +
.../datahub-gpo-report-visibility.test.ts | 15 +-
.../datahub-tenant-detail-reference.test.ts | 7 +-
tests/features/gpo-work-projection.test.ts | 70 ++++++
tests/features/linked-results.test.ts | 23 ++
.../features/policy-analysis-actions.test.tsx | 9 +
tests/features/policy-analysis-panel.test.tsx | 20 +-
tests/features/result-message.test.ts | 17 ++
.../results-browser-timeslot-scope.test.ts | 12 +-
tests/features/tile-card.test.ts | 8 +
tests/features/tile-segment-grammar.test.ts | 12 +-
tests/local-only-check.mjs | 5 +-
...icy-evaluation-rule-catalog-loader.test.ts | 100 ++++++++
49 files changed, 2162 insertions(+), 281 deletions(-)
create mode 100644 server/gpo/policy-evaluation-rule-catalog-loader.ts
create mode 100644 src/exports/unified-result-jsonl.ts
create mode 100644 src/features/linked-results/maester-error.ts
create mode 100644 src/features/project-import/policy-observations-to-dataset.ts
create mode 100644 tests/domain/gpo-unified-result.test.ts
create mode 100644 tests/exports/unified-result-jsonl.test.ts
create mode 100644 tests/features/dashboard-progressive-disclosure.test.tsx
create mode 100644 tests/features/gpo-work-projection.test.ts
create mode 100644 tests/server/policy-evaluation-rule-catalog-loader.test.ts
diff --git a/docs/IMPLEMENTATION_PLAN.md b/docs/IMPLEMENTATION_PLAN.md
index 2610642..3b058c9 100644
--- a/docs/IMPLEMENTATION_PLAN.md
+++ b/docs/IMPLEMENTATION_PLAN.md
@@ -373,6 +373,42 @@ Abnahmekriterien:
Status: abgeschlossen
+Verifizierte Result-DB-Filter-/Exportnachschaerfung vom 2026-09-03: Die Result DB startet und resettiert mit `Deviation = Yes`. Ein neuer `Export JSONL`-Button exportiert nicht nur die geladene Seite, sondern die vollstaendige aktuelle Filter- und Timeslot-Ergebnismenge ueber stabile Seitenabfragen. Zeile eins dokumentiert Format-/Schemaversion, Zeitpunkt, Scope, angewandte Filter und Ergebnisanzahl; danach folgt je Result genau ein vollstaendiges JSON-Objekt. Aendert sich die Ergebnismenge waehrend des Exports, wird der Download fail-closed abgebrochen. Drei fokussierte Export-/Scope-Tests und der Gesamtlauf mit 767 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Client-Info-Balkenformatierung vom 2026-09-03: Die wiederverwendeten Kennzahlzeilen besitzen nun identische Label-, Balken- und Wertspalten sowie eine in jeder Zeile reservierte Statuszeile. Optionale `Restricted`-Hinweise verschieben dadurch keine Nachbarzeilen mehr; Zahlen, Einheiten und Balken bleiben ueber alle gleich breiten Karten ausgerichtet. Die kompakte Infrastructure-&-Resilience-Ausnahme behaelt ihre eigenstaendige Einspaltengeometrie. 13 fokussierte Dashboard-/Kacheltests, der Gesamtlauf mit 767 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierter Work-Kachelvertrag vom 2026-09-03: Regulaere Finding-Kacheln verwenden die Nutzerreferenz als verbindliches Mindestformat mit 358 px Breite und 223 px Hoehe. Das Raster streckt unvollstaendige Reihen nicht mehr auf Restbreite; Hexagon, Titel und rechte Aktionsspalte bleiben im Kopf. Die Metadaten folgen einer festen semantischen Matrix aus Status, Kategorie, Severity plus Weight und Score. Die Hoehe darf bei laengerem Inhalt weiter wachsen; Pathfinder-Micro-Cards bleiben von der Work-spezifischen Anordnung ausgenommen. 16 fokussierte Kachel-/Typografie-/Pathfinder-Tests, der Gesamtlauf mit 768 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Infrastructure-&-Resilience-Korrektur vom 2026-09-03: Die inhaltsreiche Dashboardkachel reserviert drei statt zwei Rasterzeilen und ist als gezielte Ausnahme nicht mehr an ein starres Quadratverhaeltnis gebunden. Lange, vollstaendige OS-Aufzaehlungen bleiben dadurch innerhalb der Kartenflaeche; Faktenraster, Werte und die uebrigen quadratischen Dashboardkacheln bleiben unveraendert. 14 fokussierte Dashboard-/Inset-Tests, der Gesamtlauf mit 769 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Unmittelbare responsive Nutzerkorrektur vom 2026-09-03: Die feste Drei-Zeilen-Ausnahme wird durch inhaltsbasierte Rasterhoehen ersetzt. Jede Client-Info-Inhaltskarte behaelt ihre quadratische Mindestgeometrie, darf aber anhand ihres vollstaendigen Inhalts wachsen; `Infrastructure & Resilience` verwendet eine automatische Inhaltshoehe. Die breakpointabhaengige Rastereinheit bleibt als Mindesthoehe erhalten, waehrend `minmax(..., auto)` zusaetzlichen Platz ohne Ueberlauf bereitstellt. 14 fokussierte Dashboard-/Inset-Tests, der Gesamtlauf mit 770 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Client-Info-Progressive-Disclosure-Nachschaerfung vom 2026-09-03: Die sechs reinen Zahlenkacheln bleiben unveraendert quadratisch. Alle neun vorhandenen Detailbereiche starten dagegen als kompakte Telemetriekarten mit Titel, bestehender Metainformation, fachlicher Primaermenge und proportionalem Mengenbalken. Ein zugaenglicher Plus-/Minus-Schalter blendet die vollstaendigen bisherigen Donut-, Balken- und Fakteninhalte je Karte unabhaengig ein beziehungsweise aus. Erfundene Mockup-Bereiche wurden nicht uebernommen. Inhaltsbasierte Rasterhoehen verhindern Ueberlauf auch im expandierten Zustand. 15 fokussierte Dashboard-, Interaktions- und Inset-Tests, der Gesamtlauf mit 774 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Client-Info-Panelstil-Korrektur vom 2026-09-03: Die neun Infopanels folgen nun der ausdruecklichen Nutzerreferenz. Im minimierten Zustand ist ausschliesslich die luftige Kopfzeile `Titel — Primaermenge` mit Plus sichtbar; es gibt dort keinen Balken. Erst die aufgeklappte Ansicht zeigt hohe, grosszuegig getrennte Datenzeilen mit Label, Wert und einem 72 px dicken, breiten Mengenbalken. Assessment Status und Severity Distribution verwenden ebenfalls Mengenbalken statt Donuts, behalten aber ihre vorhandenen Filteraktionen. Faktenzeilen folgen derselben luftigen Vertikalgeometrie; die fruehere kompakte Resilience-Sonderdarstellung entfaellt. Die sechs reinen Zahlenkacheln bleiben unveraendert. 12 fokussierte Layout-/Interaktionstests, alle 774 Standardtests, Local-only- und Designpruefung sowie der Client-/Server-Produktionsbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden erwartungsgemaess uebersprungen. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Unmittelbare Breitenkorrektur der Client-Info-Infopanels vom 2026-09-03: Die aufgeklappte Karte belegt im regulaeren Raster sechs statt weiterhin nur zwei Spalten. Unterhalb von 800 px verwendet sie alle vier, unterhalb von 560 px alle zwei verfuegbaren Spalten. Damit bleibt die bestaetigte linke Label-/Wertzone neben dem breiten rechten Balkenbereich innerhalb derselben Kartenflaeche; die minimierte Zwei-Spalten-Kopfzeile bleibt unveraendert. Der in der Kopfzeile bereits dargestellte Primaerwert wird expandiert nicht als erste Zeile dupliziert. Neutrale Analysepanels uebernehmen fuer ihre restlichen Mengen die rote, orange, gelbe, violette und bei Bedarf neutrale Reihenfolge der Referenz; fachlich bereits festgelegte Status-, Coverage-, PKI- und GPO-Farben bleiben erhalten. 12 fokussierte Layout-/Interaktionstests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Abschliessende bildbezogene Client-Info-Layoutkorrektur vom 2026-09-03: Die sechs quadratischen Zahlenkacheln bilden wieder eine eigene obere Sechserspur. Darunter stehen die sechs real vorhandenen Mengenpanels dauerhaft sichtbar in einem dreispaltigen Telemetrieraster; Plus/Minus steuert nur zusaetzliche Angaben und entfernt die Mengenzeilen nicht. Assessment Status und Severity Distribution sind wieder als echte Donut-Kacheln hergestellt und bilden gemeinsam mit Directory Overview die rechte Nebenspalte. Mengenzeilen verwenden die kompakte Referenzgeometrie mit 64 px Zeilenhoehe und 30 px dicken Balken; die bisherige uebergrosse 120-/72-px-Ausfuehrung und die expandierte Sechs-Spalten-Sonderbreite sind damit supersediert. Bei kleineren Viewports reduzieren sich Mengenraster und Donutspalte kontrolliert beziehungsweise stapeln sich. 12 fokussierte Layout-/Interaktionstests, die Gesamtsuite mit 774 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Client-Info-Erstreihenkorrektur vom 2026-09-03: Die obere Zone teilt sich jetzt im selben 3:1-Verhaeltnis wie der Inhaltsbereich. Die sechs weiterhin quadratischen Zahlenkacheln belegen verkleinert das linke Dreiviertel; `Assessment Status` steht als Donut-Kachel direkt rechts daneben in Reihe 1. Dadurch ruecken `Severity Distribution` und anschliessend `Directory Overview` in der rechten Rail jeweils nach oben. Unterhalb von 1100 px stapelt sich die Kopfzone und die Zahlenkacheln wechseln kontrolliert auf drei, unterhalb von 800 px auf zwei Spalten. 12 fokussierte Layout-/Interaktionstests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Client-Open-Standardansicht vom 2026-09-03: Das direkte Oeffnen eines Clients beziehungsweise seiner ausgewaehlten Timeslots aus Data Hub fuehrt ab jetzt in `Client Info` statt `Work`. Projektname, Projekt-ID und die konkrete ScanRun-Auswahl werden unveraendert uebernommen; nur das initial aktive Hauptgebiet aendert sich. Bewusste spaetere Navigation zu Work, Result DB oder Pathfinder bleibt unveraendert. Neun fokussierte Data-Hub-/Header-/Clientdetailtests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Client-Info-Minimierkorrektur vom 2026-09-03: Alle neun Informationskacheln starten vollstaendig geoeffnet mit Minus und lassen sich nun ueber denselben zugaenglichen Schalter auf ihre reine Kopfzeile mit Plus minimieren. Das gilt einheitlich fuer die sechs Mengen-/Faktenkarten sowie Assessment Status, Severity Distribution und Directory Overview; beim erneuten Oeffnen wird der vollstaendige Inhalt wiederhergestellt. Minimierte Karten werden auch in Rasterzeilen mit hoeheren Nachbarkarten nicht mehr leer auf deren Hoehe gestreckt. Die sechs reinen Zahlenkacheln bleiben unveraendert. Die beiden gemeinsamen Kartenvertraege und alle neun konkreten Titel/Instanzen sind synthetisch beziehungsweise statisch regressionsgeprueft. 13 fokussierte Dashboard-/Interaktionstests, die Gesamtsuite mit 776 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Maester-Fehlerdarstellung vom 2026-09-03: Eindeutig erkannte `Invoke-MgGraphRequest`-Ausfuehrungsfehler werden im Results-Fenster nicht mehr als unstrukturierter Inline-Rohtext dargestellt. Die eigentliche Graph-Fehlermeldung steht als lesbare Primaeraussage oben; Fehlercode, HTTP-Status, Methode und Endpunkt, Skriptquelle, Zeit sowie vorhandene Request-IDs folgen als beschriftete strukturierte Felder. Der vollstaendige unveraenderte Quelltext bleibt unter `Technical details` einklappbar. Normale Maester-Ergebnisse und andere Werkzeuge verwenden weiterhin die generische Rich-Text-Darstellung. 48 fokussierte Result-/Reader-Tests und Client-/Server-Produktionsbuild, Local-only- sowie Designpruefung sind erfolgreich. Der parallele Gesamtlauf bestaetigt 777 Tests; genau eine fachlich unabhaengige statische Result-DB-Scope-Pruefung erwartet noch die alte Quelltextform vor der bereits parallel vorhandenen `assessmentIds`-Ergaenzung, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Client-Info-Infrastrukturtrennung vom 2026-09-03: Der Faktenblock mit `Marked findings`, AD Recycle Bin, Backupzeit, krbtgt-Aenderung, Legacy/Windows LAPS, WEF und vollstaendiger OS-Angabe ist aus `Infrastructure & Resilience` herausgeloest und steht als eigene minimierbare Kachel `Infrastructure Details` im dreispaltigen Inhaltsraster. Die Ursprungskachel enthaelt nur noch ihre Risiko-/Mengenwerte. Alle bestehenden Werte stammen unveraendert aus demselben normalisierten Environment Snapshot. Die Client-Info-Ansicht umfasst damit zehn statt neun Informationskacheln. 13 fokussierte Dashboard-/Interaktionstests, Local-only- und Designpruefung sind erfolgreich. Der Baseline-Build ist derzeit unabhaengig von dieser Aenderung durch eine parallel hinzugekommene GPO-Testfixture mit fehlendem Pflichtfeld `ImportProcessorReference.kind` blockiert; ein separater direkter Vite-Lauf war in der Sandbox wegen `spawn EPERM` nicht zulaessig. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Client-Info-Masonry-/Dreieckskorrektur vom 2026-09-03: Das Inhaltsraster misst jede der zehn Informationskacheln individuell und weist ihr eine eigene feingranulare Rasterspanne zu. Bei Collapse sinkt die Kartenhoehe auf die Kopfzeile; nachfolgende Karten belegen per dichtem Auto-Flow unmittelbar den frei gewordenen Platz, statt bis zum Ende einer hoeheren Nachbarkarte zu warten. Ohne `ResizeObserver` bleibt das regulaere nicht ueberlappende Raster als Fallback aktiv. Die Plus-/Minus-Zeichen sind durch die gemeinsamen SVG-Dreiecke ersetzt: unten fuer geoeffnet, rechts fuer geschlossen. 16 fokussierte Dashboard-, Interaktions-, Masonry- und Dreieckstests sowie Client-/Server-Produktionsbuild, Local-only- und Designpruefung sind erfolgreich. Der Gesamtlauf bestaetigt 781 Tests; genau eine unabhaengige statische Data-Hub-Open-Regression erwartet noch die alte einzeilige Quelltextformatierung, obwohl dieselbe `dashboard`-Navigation weiterhin mehrzeilig vorhanden ist; 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Client-Info-Spalten-/KPI-Korrektur vom 2026-09-03: Die freie Masonry-Neuanordnung ist zugunsten drei dauerhafter Inhalts-Spalten mit der Kartenverteilung 3/2/2 ersetzt. Karten wachsen und schrumpfen nur innerhalb ihrer zugewiesenen Spalte; beim Minimieren rueckt ausschliesslich der darunterliegende Inhalt derselben Spalte nach oben. Die sechs KPI-Kacheln strecken sich in der Desktop-Kopfzone auf die Hoehe des danebenstehenden `Assessment Status`, sodass zwischen Kopf- und Inhaltszone keine uebergrosse Leerstelle verbleibt. Die Reihenfolge lautet Compliance Score, Deviation, High Severity, Passed, Typed Observations, Directory Sections; nur Deviation und High Severity sind interaktiv. Alle KPI-Werte sind groesser, der Compliance Score verwendet die staerkste gemeinsame H1-Hierarchie. 15 fokussierte Dashboard-/Interaktions-/Dreieckstests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Im Gesamtlauf bestanden 780 Tests; eine unabhaengige statische Data-Hub-Open-Pruefung erwartet weiterhin eine einzeilige Quelltextformatierung der funktional vorhandenen mehrzeiligen `dashboard`-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Client-Info-Detailkorrektur vom 2026-09-03: Minimierte Informationskarten behalten nun mit `width: 100%` dieselbe volle Spaltenbreite wie ihre maximierte Form; nur die Kartenhoehe wird reduziert. Der werkzeugspezifische Hinweis `PingCastle` beziehungsweise dessen Engine-Version ist aus `Directory Overview` entfernt, waehrend die normalisierten Quelldaten unveraendert erhalten bleiben. 13 fokussierte Dashboard-/Interaktionstests und der Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte Client-Info-Standardansicht vom 2026-09-03: Beim Oeffnen ist ausschliesslich `Assessment Status` expandiert. Die acht uebrigen Mengen-/Faktenkarten sowie `Severity Distribution` starten als vollbreite minimierte Kopfzeilen mit rechtem Dreieck und koennen weiterhin individuell geoeffnet werden. 15 fokussierte Dashboard-/Interaktions-/Dreieckstests und der Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
Ziele:
- Filter aus normalisierten Rollen und tatsächlichen Datenwerten erzeugen.
@@ -1198,6 +1234,16 @@ Abnahmekriterien:
Status: in Arbeit
+Aktueller verifizierter Zusatzstatus vom 2026-09-03: Die bislang fehlende GPO-Anbindung an Work und Result DB ist als additives, timeslotgebundenes Readmodell geschlossen. Jede aktuelle rohe `PolicyObservation` wird als eigener Quelltyp `policy-observation` mit Assessment-, Artefakt-, Backup-, Parser-, Reducer-, Identity-, Wert-, Diagnose- und Locator-Provenienz projiziert. Diese Datensaetze bleiben fachlich `informational`, zeigen IOE und Deviation als nicht anwendbar und werden auch unter dem Result-DB-Standardfilter `Deviation = Yes` als Kontext sichtbar; nur die Finding Factory darf weiterhin eine echte `policy_deviation` erzeugen. Work fuegt `Group Policy · Observations` als eigenes Blatt hinzu und nimmt dieselben Zeilen in `All Records` auf, sodass `Source: Scan` dort `Group Policy` anbietet. Der freigegebene Dummy-Timeslot liefert ueber die laufende PostgreSQL-API 452 Scannerabweichungen plus 51 GPO-Beobachtungen, insgesamt 503 sichtbare Resultate. 13 fokussierte Tests und der Gesamtlauf mit 781 bestandenen sowie 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine SQL-Migration und keine Veraenderung der importierten Originaldaten; Phase 13B bleibt fuer fachliche Identity-/Regelkataloge und bestaetigte Policy-Findings in Arbeit.
+
+Aktueller verifizierter Zusatzstatus vom 2026-09-03: Die bislang implementierte, aber nicht erreichbare Policy-Analyseoberflaeche ist nun aus dem Data-Hub-Clientdetail zugreifbar. Eine erfolgreiche GPO-Quellenzeile verwendet keine irrefuehrende deaktivierte Scanner-Auswahlbox mehr, sondern eine eigene Quellenmarkierung und eine `View`-Aktion. Diese oeffnet die projektgebundene GPO-Analyse mit Reprocessing, Environment Profiles, Aggregation, Evaluation, Finding Factory, aktueller Summary, Historie und Review Queue; zur Stammdatenansicht kann direkt zurueckgewechselt werden. `Source: Scan` bleibt fachlich auf Scanner-Runs begrenzt. Sieben fokussierte Data-Hub-/Policy-UI-Tests, die Gesamtsuite mit 775 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt in Arbeit.
+
+Aktueller verifizierter Zusatzstatus vom 2026-09-03: GPO-Backups sind im ausgewaehlten Data-Hub-Timeslot nun als eigene Quellenzeilen sichtbar und werden im Quellenzaehler beruecksichtigt. Die Ansicht aktualisiert sich unmittelbar nach einer GPO-Einreichung; Queue-, Verarbeitungs-, Teil-, Erfolgs-, Recovery- und Dead-Letter-Zustaende bleiben unterscheidbar, und fehlgeschlagene Importe koennen direkt wiederholt oder geloescht werden. Der Browser bietet getrennte Eingaben fuer einen normalen GPO-Backup-Ordner und ein bereits vorhandenes ZIP. Ein Ordner wird weiterhin lokal in ein deterministisches Transport-ZIP verpackt, waehrend ein ZIP unveraendert dieselbe projekt- und timeslotgebundene, gehaertete Backend-Ingestion durchlaeuft. 14 fokussierte Data-Hub-/Transport-/HTTP-Tests sowie die Gesamtsuite mit 774 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt in Arbeit.
+
+Aktueller verifizierter Zusatzstatus vom 2026-09-03: Der bisher nur eingebettete fachlich leere Policy-Evaluation-Regelkatalog besitzt nun eine lokale, betriebsseitig kontrollierte Ladegrenze. Ein kuratierter JSON-Katalog wird ausschliesslich bei gemeinsam konfiguriertem Dateipfad und SHA-256 geladen, ist auf 5 MiB und regulaere Nicht-Symlink-Dateien begrenzt und wird erst nach Hash-, UTF-8-/JSON-, Struktur- und vollstaendiger fachlicher Katalogvalidierung aktiviert. Jede Abweichung verhindert den Serverstart noch vor Aufbau der Repository-Laufzeit; ohne Konfiguration bleibt der sichere leere Freigabekatalog aktiv. Drei neue synthetische Loaderregressionen, 28 fokussierte Katalog-/Evaluations-/HTTP-Tests sowie die Gesamtsuite mit 773 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Netzwerk-, API-, SQL- oder Persistenzaenderung; fachliche Regeln und Windows-Inbox-ADMX-/ADML-Inhalte bleiben bis zur autorisierten Kuratierung weiterhin leer beziehungsweise offen.
+
+Aktueller verifizierter Zusatzstatus vom 2026-09-03: Die offene snapshotbezogene Ergebnisdeduplizierung ist als additive aktuelle Sicht im Policy-Analyse-Readmodell umgesetzt. Die unveraenderliche Run-Historie bleibt vollstaendig erhalten; Summary und Review Queue zaehlen dagegen nur die aktiven Ketten aus nicht ersetztem Environment Profile, neuester nicht ersetzter Identity-Analyse je Artefakt, dazu passender Snapshotaggregation, neuester Evaluation je Aggregation und neuestem Finding-Run je Evaluation. Veraltete Ketten werden auch nicht mehr als ausfuehrbare Evaluate-/Finding-Aktionen angeboten. Drei Domainregressionen sowie Panel-, Actions- und HTTP-Regression sind erfolgreich; Gesamtsuite mit 770 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind gruen. Keine Persistenz- oder SQL-Aenderung; das Readmodell wurde additiv erweitert und Phase 13B bleibt fuer fachliche Regel-/Inbox-ADMX-Kuratierung, weitere Preference-CSEs und Exportdetails in Arbeit.
+
Aktueller verifizierter Zusatzstatus vom 2026-08-26: Die Freigabegrenze des weiterhin fachlich leeren Policy-Evaluation-Regelkatalogs validiert nun alle Runtime-Enumwerte fuer Auslieferungsmechanismus, Baseline-Disposition, Comparator und Severity, blockiert ueberlappende Selektoren beziehungsweise mehrdeutige Regeln und lehnt widerspruechlich wiederverwendete Risiko- oder Abhaengigkeits-IDs fail-closed ab. Es wurden keine Policyempfehlung und keine Severity erfunden oder freigegeben. Der lokale private Artefaktspeicher wurde vom veralteten fremden Benutzerpfad auf den aktuellen LocalAppData-Pfad ausserhalb des Webroots korrigiert; Backend, App und Speicherroot sind inhaltsfrei technisch erreichbar. Neun neue Katalogregressionen, 25 fokussierte GPO-/Katalogtests, die Gesamtsuite mit 764 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt in Arbeit.
Aktueller verifizierter Zusatzstatus vom 2026-08-22: Der globale Microsoft-Security-Baselinekatalog besitzt nun einen bestaetigungspflichtigen Delete-Pfad durch UI, Same-Origin-API, Service sowie Local- und PostgreSQL-Repository. Nur nicht von Policy-Evaluationen referenzierte Pakete duerfen geloescht werden; Klassifikationen und gespeicherte Analysen werden zusammen mit dem Katalogeintrag entfernt, das private Originalobjekt anschliessend best-effort bereinigt. Keine SQL-Migration; Phase 13B bleibt in Arbeit.
@@ -1357,7 +1403,7 @@ Abnahmekriterien:
Die naechste Umsetzung fuehrt Phase 13B auf dem konsolidierten Import-, Policy-Analyse- und Orchestrierungsunterbau fort:
1. Phase 13A ist abgeschlossen: Erkennung, technische Dokumenttypen, Source Extractors, Mappingprofile, Finding-Identität sowie allgemeine Artefakt-, Processing- und Jobgrenzen sind konsolidiert und die Scannerpersistenz verwendet den Candidate-Pfad.
-2. Phase 13B ist in Arbeit: Der sichere Ingestion-Unterbau, technische Policy-Identitaeten, versionierte ADMX-/Baselineanalysen, deterministisches Reprocessing, Environment Profiles, konservative Snapshotaggregation, typisierte Evaluation, fail-closed Finding Factory, Unified-Result-Read-Projektion sowie projektgebundene Review- und Orchestrierungsoberflaechen sind umgesetzt. Als naechste vertikale Etappe folgen fachlich kuratierte Policy-Regeln und vollstaendige versionierte Windows-Inbox-ADMX-/ADML-Kataloge; danach aktuelle snapshotbezogene Ergebnisdeduplizierung, weitere Preference-CSEs und Exportdetails. Ohne RSoP/GP Results bleibt die effektive Anwendung weiterhin ausdruecklich nicht verifiziert.
+2. Phase 13B ist in Arbeit: Der sichere Ingestion-Unterbau, technische Policy-Identitaeten, versionierte ADMX-/Baselineanalysen, deterministisches Reprocessing, Environment Profiles, konservative Snapshotaggregation, typisierte Evaluation, fail-closed Finding Factory, Unified-Result-Read-Projektion, projektgebundene Review-/Orchestrierungsoberflaechen und die aktuelle snapshotbezogene Ergebnisdeduplizierung sind umgesetzt. Als naechste vertikale Etappe folgen fachlich kuratierte Policy-Regeln und vollstaendige versionierte Windows-Inbox-ADMX-/ADML-Kataloge; danach weitere Preference-CSEs und Exportdetails. Ohne RSoP/GP Results bleibt die effektive Anwendung weiterhin ausdruecklich nicht verifiziert.
3. Erst nach verifizierter Phase 13B den kontrollierten Firmenbetrieb aus Phase 14 mit SSO, Rollen, HTTPS, Monitoring, Backup/Restore und Aufbewahrung fortsetzen.
Die technische Reihenfolge ist bis einschliesslich Phase 13A umgesetzt. Phase 13B baut auf dem verifizierten sicheren Ingestion-Unterbau auf und reicht inzwischen produktiv von der begrenzten Parser-/Workerverarbeitung ueber unveraenderliche Analyse-, Profil-, Aggregations- und Evaluationslaeufe bis zur streng evidenzgebundenen Finding Factory und ihrer gemeinsamen Unified-Result-Leseprojektion. Das Backend leitet projektgebundene Aktionsbereitschaft aus aktiven Revisionen und exakt passenden Referenzdaten ab; der Datahub fuehrt Environment-Profile-Anlage, Reprocessing, Aggregation, Evaluation und Finding Factory ueber die autoritativen idempotenten Services aus. Der produktive Regelkatalog bleibt bis fachlicher Kuratierung leer, und die vorhandenen Microsoft-Baselines bleiben ohne vollstaendige Windows-Inbox-ADMX-/ADML-Kataloge partial; dadurch erzeugt dieser reale Bestand weiterhin nur Review und keine Findings.
@@ -1368,14 +1414,39 @@ Aktualisierung nach dem Schritt-9-Vertikalschnitt vom 2026-08-04: Versionierte E
Aktualisierung nach dem Schritt-10/11-Finding-Vertikalschnitt vom 2026-08-04: Finding Factory, persistente Policy-Finding-Occurrences, projektgebundene API und Unified-Result-Read-Projektion sind fuer ausschliesslich vollstaendig belegte `eligible` konfigurierte Abweichungen umgesetzt. Unvollstaendige Evidenz bleibt als Factory-Ablehnung ausserhalb des Resultmodells; Scope und Wirksamkeit bleiben ausdruecklich unbekannt beziehungsweise nicht verifiziert. Der aktive produktive Katalog bleibt bis zur fachlichen Freigabe setting-spezifischer Regeln leer und erzeugt daher weiterhin keine Findings. Als naechster Vertikalschnitt folgt die UI fuer Konflikte, Katalog-/Parserluecken, partielle Analysen und unaufgeloeste Identitaeten; danach folgen fachliche Regelkuratierung und vollstaendige Windows-Inbox-ADMX-Kataloge. Weitere Preference-CSEs bleiben ein getrenntes Arbeitspaket.
Aktualisierung nach dem Schritt-11-UI-Vertikalschnitt vom 2026-08-04: Konflikte, partielle Analysen, Katalog-/Parserluecken, unaufgeloeste Identitaeten, unbekanntes Targeting und Finding-Factory-Ablehnungen sind nun projektgebunden ueber ein typisiertes Readmodell, eine read-only API und den Datahub sichtbar. Findings und Review bleiben getrennt; Laufhistorie wird nicht als deduplizierter aktueller Kundenzustand bezeichnet, und die fehlende RSoP-/GP-Results-Evidenz bleibt sichtbar. Der unmittelbar folgende Orchestrierungsvertikalschnitt erweitert diese read-only Ansicht um bedienbare Environment-Profile-, Reprocessing-, Aggregations-, Evaluations- und Finding-Factory-Aktionen; fachlich kuratierte Regel- und Windows-Inbox-ADMX-Kataloge, weitere Preference-CSEs und Exportdetails bleiben getrennte Arbeitspakete.
Aktualisierung nach dem Schritt-11-Orchestrierungsvertikalschnitt vom 2026-08-04: Environment Profiles und ihre Revisionen koennen nun im Datahub angelegt werden; GPO-Reprocessing, Aggregation, Evaluation und Finding Factory sind ueber serverseitig abgeleitete Ready-/Review-only-/Completed-/Blocked-Aktionen bedienbar. Katalogauswahl, aktive Revisionen und technische Quellen werden im Backend-Readmodell bestimmt, waehrend jede Mutation ihre bestehenden Fachinvarianten erneut prueft. Als naechste Vertikalschnitte folgen die fachlich kuratierten Policy-Regeln und vollstaendigen Windows-Inbox-ADMX-Kataloge sowie danach aktuelle snapshotbezogene Ergebnisdeduplizierung, weitere Preference-CSEs und Exportdetails.
+Aktualisierung nach der snapshotbezogenen Ergebnisdeduplizierung vom 2026-09-03: Das Policy-Analyse-Readmodell trennt nun den aktuellen aktiven Snapshotpfad von der weiterhin vollstaendigen Audit-Historie. Summary, Review Queue und ausfuehrbare Folgeaktionen verwenden nur die aktive Revisionskette; historische Evaluationen bleiben separat sichtbar. Als naechste fachliche Etappen verbleiben kuratierte Policy-Regeln und vollstaendige Windows-Inbox-ADMX-/ADML-Kataloge, danach weitere Preference-CSEs und Policy-Exportdetails.
+Aktualisierung nach der Katalog-Ladegrenze vom 2026-09-03: Fachlich freigegebene Policy-Regeln koennen nun als lokal betriebener, SHA-256-gepinnter und vollstaendig validierter JSON-Katalog reproduzierbar aktiviert werden; der Default bleibt leer und fail-closed. Als naechster fachlicher Schritt sind ein autorisiert kuratierter Regelinhalt und vollstaendige versionierte Windows-Inbox-ADMX-/ADML-Quellen erforderlich; weitere Preference-CSEs und Policy-Exportdetails bleiben danach offen.
## 9. Bereits getroffene Architekturentscheidungen
| Datum | Entscheidung | Begründung |
+| 2026-09-03 | Die verbindliche Client-Info-Startansicht expandiert nur `Assessment Status`; alle neun anderen Informationskarten starten minimiert. | Der Gesamtstatus bleibt ohne Interaktion sichtbar, waehrend die darunterliegende feste 3/2/2-Matrix und die rechte Rail als kompakte, stabile Navigation beginnen. Inhalte werden nicht entfernt und bleiben ueber die Standarddreiecke einzeln erreichbar. |
+| 2026-09-03 | Minimierte Client-Info-Karten bleiben ueber die volle Breite ihrer festen Spalte gespannt. `Directory Overview` zeigt keine werkzeugspezifische PingCastle-Engine-Version mehr. | Collapse soll ausschliesslich die Hoehe reduzieren und darf die stabile Spaltengeometrie nicht veraendern. Die Directory-Karte beschreibt den Verzeichniszustand; eine Scanner-Engine-Version gehoert nicht zu diesem fachlichen Ueberblick und bleibt nur in der unveraenderten Provenienz erhalten. |
+| 2026-09-03 | Das Client-Info-Hauptraster verwendet drei feste Karten-Spalten mit der dauerhaften Zuordnung 3/2/2 und keine dichte Masonry-Neuverteilung mehr. Collapse veraendert nur die Hoehe innerhalb derselben Spalte. Die Desktop-KPI-Matrix streckt ihre sechs Karten auf die Hoehe von `Assessment Status`; ihre feste Reihenfolge ist Compliance Score, Deviation, High Severity, Passed, Typed Observations, Directory Sections. Nur Deviation und High Severity sind Filteraktionen. | Die ausdrueckliche Nutzeranforderung priorisiert stabile raeumliche Orientierung gegenueber global maximaler Verdichtung. Feste Spalten verhindern Positionswechsel beim Minimieren und Maximieren; die gemeinsame Kopfhoehe beseitigt die grosse Leerstelle. Begrenzte Klickziele vermeiden versehentliche Filterwechsel, waehrend die staerkere Compliance-Hierarchie den wichtigsten Gesamtwert hervorhebt. Diese Entscheidung supersediert die unmittelbar folgende Masonry-Entscheidung. |
+| 2026-09-03 | Rohe aktuelle GPO-Policy-Beobachtungen werden als eigener Unified-Result-Quelltyp `policy-observation` timeslotgebunden in Result DB und Work dargestellt. Sie sind Kontext-/Reviewdaten mit nicht anwendbaren Finding-Achsen und werden niemals allein durch die Sichtprojektion zu Abweichungen oder Findings. Diese Nutzerkorrektur supersediert fuer die gemeinsame Work-Ansicht die unmittelbar folgende fruehere Beschraenkung von `Source: Scan`: Dort erscheint nun auch `Group Policy`; im Data-Hub bleibt das Backup weiterhin kein auswaehlbarer Scanner-Run. | GPO-Inhalte muessen nach dem Import konkret auffindbar und exportierbar sein, auch solange Identity-, Baseline- oder Risikokataloge noch keine bestaetigte Abweichung erlauben. Die getrennte Quellart schliesst die Sichtbarkeitsluecke, ohne die konservative Finding-Factory-Grenze aufzuweichen. |
+| 2026-09-03 | GPO-Backups verwenden im Timeslot keine Scanner-Auswahlbox. Eine eigene Quellenmarkierung und `View` oeffnen die projektgebundene Policy-Analyse; `Source: Scan` bleibt ausschliesslich der Provenienzfilter fuer Scanner-Runs. | Ein GPO-Backup ist verarbeitbare Policy-Evidenz, aber kein kanonischer Scanner-Run. Eine deaktivierte Checkbox suggeriert fehlende Berechtigung oder Nichtauswaehlbarkeit, waehrend eine explizite Anzeigeaktion die vorhandenen Analysedaten erreichbar macht, ohne GPO-Evidenz faelschlich in den Scanner-Scope umzudeuten. |
+| 2026-09-03 | GPO-Backups werden im Data-Hub-Timeslot als eigene Quellen neben Scanner-Reports dargestellt. Ordnerauswahl und vorhandenes ZIP sind getrennte UI-Wege, verwenden aber dieselbe projekt- und timeslotgebundene Backend-Ingestion; nur der Ordnerweg erzeugt zuvor lokal das deterministische Transport-ZIP. | Die bislang bereits gespeicherten GPO-Quellen duerfen nicht unsichtbar bleiben oder als Scanner-Run erscheinen. Zwei eindeutige Eingaben vermeiden Missverstaendnisse, ohne die gehärtete Validierungs-, Speicher- und Jobgrenze zu duplizieren oder aufzuweichen. |
+| 2026-09-03 | Ein kuratierter Policy-Evaluation-Regelkatalog wird nur aus einer lokalen regulaeren Datei geladen, wenn Pfad und erwarteter SHA-256 gemeinsam konfiguriert sind. Der Hash wird vor Parsing und fachlicher Validierung geprueft; ohne Konfiguration bleibt der eingebettete leere Freigabekatalog aktiv. | Kataloginhalte bestimmen sicherheitsrelevante Abweichungen und Severities. Eine explizite Hashbindung macht den freigegebenen Stand betriebsseitig nachvollziehbar, verhindert stillen Dateidrift und bewahrt den local-only Betrieb ohne automatischen Download oder implizite Aktivierung. |
+| 2026-09-03 | Das Policy-Analyse-Readmodell fuehrt neben der unveraenderlichen Run-Historie eine explizite aktuelle Sicht. Aktuell sind nur die durch aktive Profil- und Identity-Revisionen erreichbaren Aggregationen mit jeweils ihrer neuesten Evaluation und ihrem neuesten Finding-Run; Summary, Review Queue und Folgeaktionen werden daraus abgeleitet. | Reprocessing darf alte Konflikte, Katalogluecken, Abweichungen und Findings nicht als aktuellen Kundenzustand doppelt zaehlen. Gleichzeitig muss jeder fruehere Lauf fuer Audit und Reproduzierbarkeit erhalten bleiben. Dieselbe Aktivkettenselektion fuer Anzeige und Aktionen verhindert Bedienung auf veralteten Analysestaenden. |
|---|---|---|
| 2026-09-11 | ASSESSOR erweitert den unveraenderten externen `result_type`-Katalog additiv um `vulnerability_finding`. Defender-for-IoT-CVEs erhalten bei fehlendem Quellstatus deklarativ `outcome=warning`; sie sind damit Abweichungen, bleiben aber `is_ioe=false`. `environment-observation` bleibt eine Herkunftsart mit `result_type=informational`. | Eine konkrete CVE auf betroffenen Devices ist weder Compliance-Check noch Policy-Abweichung oder blosse Inventarinformation. `exposure_finding` wuerde die vorhandene Exposure-State-/IOE-Semantik unnoetig auf Schwachstellen ausdehnen. Der eigene Typ trennt Schwachstellenbefund, Dringlichkeit und bestaetigte Exposure weiterhin sauber. |
| 2026-09-10 | NVD `configurations` bleiben als top-level Konfigurationsgruppen erhalten. Vulnerable CPE-Matches bilden die betroffene Software je Gruppe; nicht vulnerable Matches derselben Gruppe werden getrennt als `Running on/with` gespeichert und dargestellt. Das Enrichment-Recordformat ist dafuer Version 2; Version-1-Flachsaetze bleiben lesbar, muessen fuer die verlustfreie Gruppierung aber erneut von NVD abgerufen werden. | Die NVD-Oberflaeche und API beschreiben eine logische Konfiguration aus betroffener Software und ihren Laufzeit-/Hardwarebedingungen. Ein flaches Match-Array ueberzaehlt Konfigurationen und verliert genau diese Beziehung. Die Gruppierung muss deshalb vor der Persistenz im externen Referenzadapter erhalten werden. |
| 2026-09-10 | CVE-Enrichment ist ein globaler, nach normalisierter CVE-ID identifizierter Referenzbestand und weder Bestandteil der tenant-/timeslotgebundenen FindingOccurrence noch der werkzeuggebundenen, durch Reimport ersetzbaren FindingDefinition. Defender-Import und NVD-Enrichment bleiben getrennt; nur eine ausdrueckliche Aktion fuer eine bereits gespeicherte Defender-CVE darf den festen NVD-Endpunkt abfragen. | Beschreibung, CVSS-Metriken, CWE, Referenzen und betroffene Konfigurationen beschreiben die CVE selbst. Ein gemeinsamer Datensatz vermeidet redundante, auseinanderlaufende Kopien und macht vorhandene Anreicherung fuer spaetere Mandanten automatisch wiederverwendbar, waehrend der Import ohne Netzabhaengigkeit reproduzierbar bleibt. |
+| 2026-09-03 | Das Client-Info-Hauptraster verwendet eine Progressive-Enhancement-Masonry-Berechnung auf Basis real gemessener Kartenhoehen. Erst nach erfolgreicher Messung aktiviert es feine 1-px-Tracks und dichten Auto-Flow; ResizeObserver aktualisiert die Spannen bei Collapse, Inhalts- und Breitenwechseln. Zustandsbuttons verwenden das gemeinsame `TriangleIcon` unten/rechts. | Ein regulaeres CSS Grid reserviert pro Zeile die Hoehe der groessten Karte und kann kuerzere geschlossene Karten nicht unabhaengig nach oben packen. Die gemessene Span-Berechnung ermoeglicht echtes Nachruecken, waehrend das vor der Messung aktive Standardraster einen sicheren Fallback ohne Ueberlagerung bildet. Gemeinsame SVG-Dreiecke sind schrift- und kodierungsunabhaengig und entsprechen der bestehenden App-Konvention. |
+| 2026-09-03 | Die Environment-Fakten `Marked findings`, AD Recycle Bin, Backup/krbtgt, LAPS, WEF und OS bilden eine eigene Client-Info-Kachel `Infrastructure Details`; `Infrastructure & Resilience` bleibt eine reine Mengen-/Risikokarte. Beide verwenden denselben gemeinsamen minimierbaren Kartenvertrag. | Risikoindikatoren und beschreibende Infrastrukturwerte sind zwei unterschiedliche Informationsarten. Eine eigene Kachel bewahrt die luftige Faktengeometrie, verhindert eine ueberlange Mischkarte und laesst beide Gruppen unabhaengig minimieren, ohne ihre gemeinsame Snapshotquelle zu veraendern. |
+| 2026-09-03 | Maester-`Invoke-MgGraphRequest`-Ausfuehrungsfehler erhalten eine additive strukturierte Praesentation mit Primaermeldung, technischen Schluesselfeldern und standardmaessig eingeklapptem vollstaendigem Rohtext. Die Erkennung und Extraktion liegt in einem reinen werkzeugspezifischen Parser ausserhalb der React-Komponente; nicht erkannte Texte fallen verlustfrei auf die bestehende Rich-Text-Darstellung zurueck. | Lange PowerShell-/HTTP-/JSON-Ketten sind in einer Fliesstextzeile nicht diagnostizierbar. Die Trennung hebt die handlungsrelevante Graph-Ursache hervor, bewahrt Request-Korrelation und Originalbeleg und haelt source-spezifische Interpretation aus der allgemeinen Darstellungskomponente heraus. |
+| 2026-09-03 | Alle neun Client-Info-Informationskacheln verwenden einen gemeinsamen vollstaendig minimierbaren Interaktionsvertrag: initial geoeffnet mit Minus, minimiert ausschliesslich die Kopfzeile mit Plus und intrinsischer Kopfzeilenhoehe, erneut geoeffnet mit vollstaendigem Inhalt. Die sechs reinen Zahlenkacheln bleiben nicht minimierbar und unveraendert. | Der vorherige Schalter veraenderte bei den sechs Mengen-/Faktenkarten nur optionale Zusatzangaben und fehlte bei Donutkarten teilweise, obwohl die Bedienung als Minimieren verstanden wird. Ein identischer Vertrag fuer beide gemeinsamen Kartenkomponenten plus ein explizites `align-self: start` im minimierten Zustand verhindert wirkungslose Schalter und leere, auf Nachbarhoehe gestreckte Karten. |
+| 2026-09-03 | Die neueste bildlich bestaetigte Nutzerreferenz ersetzt den unmittelbar zuvor festgelegten minimierten Mengenbalken: Alle neun Client-Info-Infopanels zeigen minimiert nur `Titel — Primaermenge` und Plus. Expandiert verwenden alle mengenbezogenen Inhalte hohe Zeilen mit breitem 72-px-Mengenbalken; Assessment und Severity werden nicht mehr als Donut dargestellt. Faktenzeilen nutzen dieselbe luftige Vertikalordnung. Die sechs Zahlenkacheln bleiben unveraendert. | Der Balken ist Detailinhalt und darf die minimierte Uebersicht nicht erneut verdichten. Eine einheitliche expandierte Zeilengeometrie setzt die Referenz ueber alle Infopanels um, bewahrt reale Werte und vermeidet sowohl erfundene Verlaeufe als auch lokale kompakte Sonderlayouts. |
+| 2026-09-03 | Die abschliessende Nutzerreferenz supersediert die unmittelbar vorherige reine Collapsed-/Expanded-Geometrie: Sechs Zahlenkacheln stehen oben; sechs Mengenpanels bleiben darunter permanent als dreispaltige Uebersicht sichtbar. Plus/Minus betrifft nur Zusatzdetails. Assessment und Severity bleiben Donut-Kacheln in einer rechten Nebenspalte, Directory Overview folgt dort als Faktenkarte. | Das Zielbild zeigt die Mengenzeilen bereits bei einem Pluszustand und fordert die Donuts ausdruecklich daneben. Eine getrennte Hauptmatrix und Verteilungsspalte bildet diese Hierarchie direkt ab, ohne reale Kennzahlen zu verbergen oder Donutverteilungen in Mengenbalken umzudeuten. |
+| 2026-09-03 | Die Kopfzone von Client Info verwendet dasselbe 3:1-Verhaeltnis wie Hauptmatrix und rechte Rail: sechs verkleinerte quadratische Kennzahlen links, `Assessment Status` rechts in derselben ersten Reihe. | Der erste Donut soll ohne eine neue Zwischenreihe direkt neben den Zahlenkacheln stehen. Die gemeinsame Spaltenteilung richtet Kopf- und Inhaltszone aus und laesst die verbleibenden Rail-Karten automatisch nachruecken. |
+| 2026-09-03 | `Open Client` aktiviert nach Uebernahme des Projekt-/Timeslot-Scope standardmaessig den Hauptbereich `Client Info`; `Work` bleibt eine anschliessend bewusst waehlbare Ansicht. | Die Client-Informationsansicht ist der vereinbarte Einstieg in einen geoeffneten Mandanten. Der Scopewechsel und die Wahl des ersten Darstellungsbereichs bleiben getrennte Verantwortlichkeiten. |
+| 2026-09-03 | Ein expandiertes Client-Info-Infopanel belegt regulaer sechs Rasterspalten und an den Breakpoints die komplette verfuegbare Rasterbreite; minimiert bleibt es zwei Spalten breit. Der Kopf-Primaerwert wird im Body nicht wiederholt; neutrale Mengenserien verwenden die referenzierte ordinale Farbfolge. | Die Referenz besitzt eine breite linke Label-/Wertzone und eine ebenso breite rechte Visualisierungszone. Diese Geometrie ist in einer nur zwei Spalten breiten Karte nicht darstellbar und fuehrt zum sichtbaren Ueberlauf der Mengenbalken. Das Entfernen der ersten Doppelzeile stellt zugleich die Informationshierarchie und die vier sichtbaren Referenzreihen wieder her. |
+| 2026-09-03 | Die ausdrueckliche AMD-Adrenalin-inspirierte Nutzerreferenz ersetzt den frueheren Quadratvertrag ausschliesslich fuer die neun Client-Info-Detailkarten. Diese starten kompakt mit einer Primaermenge und einem Mengenbalken; Plus/Minus steuert die vollstaendigen bisherigen Details je Karte. Die sechs Zahlenkacheln bleiben unveraendert quadratisch. | Progressive Disclosure erhoeht die Uebersicht, ohne Daten zu entfernen. Mengenbalken stellen den aktuellen Umfang korrekt dar, waehrend erfundene Verlaufsgraphen ohne Zeitreihe eine nicht vorhandene Entwicklung suggerieren wuerden. Die Trennung bewahrt die bestaetigte Zahlenzeile und macht alle real vorhandenen Detailbereiche bedarfsgesteuert erreichbar. |
+| 2026-09-03 | Die responsive Nutzerkorrektur ersetzt die unmittelbar zuvor festgelegten drei Rasterzeilen: Client-Info-Rasterzeilen verwenden eine breakpointabhaengige Mindestgroesse mit inhaltsbasiertem Auto-Wachstum. Inhaltskarten sind mindestens quadratisch und wachsen bei Bedarf; `Infrastructure & Resilience` besitzt eine automatische Inhaltshoehe. | Eine feste Zahl von Rasterzeilen ist kein responsives Verhalten und kann bei anderer Breite oder Datenmenge erneut zu viel oder zu wenig Platz liefern. Inhaltsbasierte Trackgroessen reagieren sowohl auf den Viewport als auch auf die tatsaechlichen Werte, ohne Clipping oder starre Leerflaeche. |
+| 2026-09-03 | Die inhaltsreiche Dashboardkachel `Infrastructure & Resilience` belegt drei Rasterzeilen und hebt ausschliesslich fuer sich das starre Quadratverhaeltnis auf; alle anderen Client-Info-Karten behalten die gemeinsame quadratische Geometrie. | Die vollstaendige dynamische OS-Liste darf weder abgeschnitten werden noch aus der Kachel herauslaufen. Eine gezielte Hoehenerweiterung bewahrt die bestehende Faktenstruktur und den dichten Gesamtrastervertrag, ohne andere Karten unnoetig zu vergroessern. |
+| 2026-09-03 | Regulaere Work-Finding-Kacheln besitzen eine feste Inhaltsbreite von 358 px und eine Mindesthoehe von 223 px; sie duerfen fuer vollstaendigen Inhalt nach unten wachsen. Die Metadatenreihenfolge ist Status, Kategorie, Severity/Weight und Score. Pathfinder-Micro-Cards behalten ihre eigenstaendige kompakte Geometrie. | Das freigegebene Referenzformat muss die untere Groessengrenze jeder Matrixkachel bilden. Eine feste Breite verhindert das Aufziehen der letzten Reihe; eine Mindest- statt Fixhoehe bewahrt lange Titel und Metadaten ohne Clipping. Die semantische Badge-Matrix erzeugt unabhaengig von der Datensatzkombination dieselbe Lesereihenfolge. |
+| 2026-09-03 | Die Result DB verwendet `Deviation = Yes` als initialen und durch `Reset filters` wiederhergestellten Arbeitszustand. Ihr LLM-Export ist versioniertes JSONL: ein Manifest mit aktivem Timeslot-/Projekt-Scope und allen Nutzerfiltern, danach eine Zeile pro vollstaendigem Unified Result. | Abweichungen sind die primaere Analysemenge. JSONL bewahrt verschachtelte Evidenz und Provenienz, bleibt an Datensatzgrenzen teilbar und ist fuer LLM- sowie maschinelle Weiterverarbeitung robuster als eine flache CSV- oder unstrukturierte Markdown-Ausgabe. Der Manifest-Snapshot macht die exportierte Auswahl reproduzierbar. |
+| 2026-09-03 | Balkenlisten in den quadratischen Client-Info-Karten verwenden dieselben drei Spalten fuer Label, Track und Wert sowie eine stets reservierte zweite Wertzeile fuer optionale Quellenhinweise. Zahlen und Einheiten bleiben in einer nicht umbrechenden Wertgruppe; die Resilience-Kompaktkarte ueberschreibt diesen Vertrag lokal mit ihrer bestehenden Einspaltenanordnung. | Eine optionale Zusatzzeile darf weder die Hoehe einzelner Eintraege noch Track- oder Wertbreiten zwischen gleichartigen Karten veraendern. Gemeinsame Spaltenrollen machen die Werte visuell vergleichbar, ohne Daten oder Kartenstruktur umzudeuten. |
| 2026-08-26 | Ein Policy-Evaluation-Regelkatalog darf den Status `released` nur tragen, wenn seine Runtime-Vertraege geschlossen validiert sind und fuer dieselbe technische Identitaet, denselben Auslieferungsmechanismus und ueberlappende Produkt-/Versions-/Rollen-/Scope-Kontexte hoechstens eine Regel aufloesbar ist. Wiederverwendete Risiko- und Abhaengigkeits-IDs muessen katalogweit dieselbe Definition besitzen. | Der kuenftige fachlich kuratierte Katalog wird an einer sicherheitsrelevanten Finding-Grenze ausgefuehrt. TypeScript-Typen allein schuetzen weder geladene noch historisch persistierte Runtime-Daten; Mehrdeutigkeit oder unbekannte Enumwerte muessen deshalb vor jeder Freigabe fail-closed blockieren. |
| 2026-08-25 | Die appweite persistente Markierungs- und Auswahlfarbe ist auf ausdrueckliche Nutzerfestlegung immer Gelb und wird in beiden Themes ueber `--marking-color` gefuehrt. Kachelauswahl, Auswahlrahmen/-marker, gemerkte Eintraege und Graphauswahl verwenden diesen Token. Blau bleibt Tastaturfokus; Gruen, Rot, Orange und Severitytoene bleiben fachliche Statussignale. | Ein einzelner semantischer Markierungston verhindert violette oder skinabhaengig wechselnde Auswahlkonturen wie im Datahub-Screenshot und bewahrt gleichzeitig die Bedeutung bestehender Statusfarben. |
| 2026-08-25 | Die unmittelbar zuvor fuer Client Info festgelegte flache SOC-Kachel ist auf ausdrueckliche Nutzerfestlegung der neue appweite Kachelstandard: keine sichtbare Normalzustandskontur, kein Radius und kein Schatten; Hover veraendert nur die Flaeche. Fokus, Auswahl und kleine Statusakzente bleiben funktionale Ausnahmen. Die gemeinsamen `--tile-*`-Tokens und Projektregeln tragen diesen Vertrag. | Ein zentraler Standard verhindert, dass neue oder bestehende Ansichten erneut weisse Konturen, Rundungen oder schwebende Schatten einfuehren. Flaechenkontrast und gemeinsamer Abstand erzeugen die gewuenschte ruhige, dichte SOC-Geometrie. |
@@ -1644,11 +1715,31 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode
## 11. Risiken
| Risiko | Gegenmaßnahme |
+| Eine spaetere Kartenrefaktorierung kann wieder alle Client-Info-Karten standardmaessig oeffnen und damit die vereinbarte kompakte Startansicht verlieren. | Den Startzustand an jeder konkreten Karteninstanz explizit setzen und statisch pruefen: neun `initiallyExpanded={false}` sowie genau ein nicht minimierter `Assessment Status`; die gemeinsame Komponente bleibt fuer gezielte Wiederverwendung konfigurierbar. |
+| Eine minimierte Client-Info-Karte kann durch intrinsische Flexbreite schmaler als ihre Spalte werden; werkzeugspezifische Provenienz kann ausserdem erneut in einen fachlichen Verzeichnisueberblick geraten. | Collapsed-Karten explizit auf `width: 100%` setzen und diese Geometrie regressionspruefen. `directoryFacts` auf fachliche Directory-Felder begrenzen; Scanner-Engine-Versionen bleiben in der Quellprovenienz statt in `Directory Overview`. |
+| Client-Info-Karten koennen beim Ein-/Ausklappen zwischen Spalten wechseln und dadurch die erlernte Position verlieren; unterschiedlich hohe Kopfbereiche koennen ausserdem eine grosse Leerstelle vor der Inhaltsmatrix erzeugen. | Karten statisch in drei semantische Spalten mit der Zuordnung 3/2/2 gruppieren und innerhalb jeder Spalte per Flex-Stack anordnen. Keine dichte Auto-Platzierung oder laufzeitbasierte Spannenberechnung verwenden. KPI-Matrix und Assessment-Status in derselben gestreckten Kopfzeile fuehren; an schmalen Breakpoints kontrolliert stapeln. Spaltenzahl, Karteninstanzen, Reihenfolge und Collapse regressionspruefen. |
+| Ein lokal bereitgestellter Policy-Regelkatalog kann nach fachlicher Freigabe unbemerkt veraendert, nur teilweise konfiguriert, als Symlink umgebogen oder mit ungueltigen Runtime-Strukturen geladen werden und dadurch andere Findings erzeugen. | Pfad und SHA-256 als untrennbares Konfigurationspaar verlangen, nur regulaere Nicht-Symlink-Dateien bis 5 MiB lesen, Hash vor UTF-8-/JSON-Parsing vergleichen und danach den geschlossenen Katalogvertrag fail-closed validieren. Bei jedem Fehler vor Repository- und Serverstart abbrechen; Evaluation Runs bewahren weiterhin den vollstaendigen tatsaechlich verwendeten Katalog. |
+| Historische GPO-Reprocessing-Ketten koennen alte Konflikte, Reviewhinweise, Abweichungen und Findings mehrfach als aktuellen Zustand erscheinen lassen; wenn UI und Aktionsableitung unterschiedliche Auswahlregeln verwenden, bleiben ausserdem veraltete Evaluationen bedienbar. | Aktive Profile und nicht ersetzte Identity-Analysen je Artefakt als Wurzel einer gemeinsamen deterministischen Aktivkette verwenden; nur dazu passende Aggregationen, jeweils neueste Evaluationen und Finding-Runs in die aktuelle Sicht aufnehmen. Historie getrennt erhalten und dieselbe Auswahlfunktion fuer Summary, Review Queue sowie Evaluate-/Finding-Aktionen regressionspruefen. |
|---|---|
| Alte Defender-Importe mit Profil 1.0.0 tragen im gespeicherten Occurrence-JSON weiterhin `outcome=unknown`; wenn Work bereits die aktuelle Profilregel verwendet, koennten Projektion und SQL-Vorfilterung widerspruechlich werden. | Profil 1.1.0 als semantisch inkompatiblen Vertrag mit neuem Compatibility Key registrieren. Die unveraenderliche Migration 022 erweitert den Result-Type-Constraint; Migration 023 zieht ausschliesslich die abgeleiteten relationalen Read-Model-Spalten `result_type` und `outcome_normalized` fuer bestehende Defender-Vorkommen nach. Originalfelder, Occurrence-JSON und Profilprovenienz bleiben unveraendert. Die Leseprojektion behandelt einen nachweislich statuslosen historischen Vulnerability-Fund ebenso. Reimport/Reprocessing bleibt fuer einen vollstaendig aktuellen kanonischen Datensatz erforderlich. |
| NVD kann nicht erreichbar oder rate-limitiert sein, unerwartet grosse Antworten liefern oder externe Referenz-URLs enthalten; ein API-Schluessel darf nicht an Browser oder Logs gelangen. Eine automatische Anreicherung waehrend des Imports wuerde zudem dessen Reproduzierbarkeit und Verfuegbarkeit an einen externen Dienst koppeln. | Enrichment ausschliesslich separat und nutzerausgeloest im Backend ausfuehren, nur exakt gespeicherte Defender-CVE-IDs akzeptieren, Zielorigin und API-Pfad fest verdrahten sowie Timeout und 8-MiB-Antwortgrenze erzwingen. Den optionalen Schluessel nur aus `NVD_API_KEY` als Serverheader senden, Antwortfelder normalisieren, Referenzen nur als HTTP(S)-Links darstellen und Importfehler strikt vom Enrichment-Ergebnis trennen. |
| Defender-for-IoT-Summarys koennen Severity-Zahlen ohne einzelne CVEs enthalten; wiederholte Sensorzeilen koennen dieselbe Device-CVE-Beziehung mehrfach melden, und pseudonymisierte oder wiederverwendete Adressen koennen Identitaeten mehrdeutig machen. | Aggregate ohne Detail niemals in Findings umwandeln, Device-mal-CVE vor der kanonischen Projektion deduplizieren, alle Sensorzeilen als Evidenz erhalten, Identitaet nach der dokumentierten MAC-/IP-/Name-Site-Reihenfolge bilden und Konflikte beziehungsweise Reconciliation-Abweichungen diagnostizieren statt still zusammenzufuehren. |
| Ein gemischtes All-Records-Blatt kann den generischen Titel `Name` auf alle Scanner anwenden und dadurch bei Defender die Device-IP statt der CVE anzeigen; zugleich kann eine rein profilgebundene Client-Info-Sonderansicht in gemischten Timeslots verschwinden. | Titel im gemischten Blatt je Datensatz aus dessen `Source: Scan`-Provenienz und deklarativem Werkzeugprofil bestimmen. Die allgemeine Client-Info-Uebersicht beibehalten und die Defender-Projektion bei vorhandenen Defender-Quellblaettern als eigenen Tab anbieten. |
+| Unterschiedlich hohe oder geschlossene Client-Info-Karten koennen in einem regulaeren Zeilenraster grosse Leerraeume hinterlassen; eine unbedingte JS-Masonry-Aktivierung koennte ohne Mess-API dagegen Karten ueberlagern. | Mit dem normalen Raster starten, Kartenhoehen inklusive gemeinsamem Segmentabstand messen und erst danach 1-px-Spannen mit `grid-auto-flow: row dense` aktivieren. Raster und jede Karte beobachten, nur geaenderte Spannen schreiben und bei fehlendem ResizeObserver im sicheren Standardraster bleiben. Synthetische DOM-Hoehen und Collapse werden regressionsgeprueft. |
+| Infrastruktur-Fakten koennten bei einer spaeteren Dashboardverdichtung erneut mit Risiko-Mengenwerten in einer ueberlangen Mischkarte zusammengefuehrt oder zwischen beiden Karten doppelt dargestellt werden. | `Infrastructure & Resilience` ausschliesslich mit `risk.slice(1)` speisen und den vollstaendigen Faktenblock genau einmal in `Infrastructure Details` rendern. Instanzzahl, beide Titel, Trennung und vollstaendige Snapshot-Faktenliste statisch regressionspruefen; beide Karten ueber den gemeinsamen Collapse-Test absichern. |
+| Maester-Fehlertexte koennen PowerShell-Kontext, HTTP-Antwort und verschachteltes JSON in einer langen Zeile mischen; eine aggressive Umformatierung koennte dabei Diagnosewerte verlieren oder normale Ergebnisprosa faelschlich als Fehler behandeln. | Nur die eindeutige Kombination aus Maester, Ausfuehrungsfehlerformulierung und `Invoke-MgGraphRequest` strukturiert parsen. Die Primaermeldung und bekannte technische Felder additiv extrahieren, den unveraenderten Rohtext stets einklappbar erhalten und bei jeder Nichterkennung auf den generischen Renderer zurueckfallen. Parser und Darstellung mit synthetischen Fehlern regressionspruefen. |
+| Eine Client-Info-Kachel koennte einen Plus-/Minus-Schalter anzeigen, ohne ihren gesamten Inhalt zu minimieren, in einer hohen Rasterzeile als leere Vollhoehenkarte stehen bleiben oder zwischen Donut- und Faktenkarten unterschiedliche Zustandslogik verwenden. | Beide gemeinsamen Informationskartenkomponenten rendern im minimierten Zustand strukturell nur die Kopfzeile, verwenden dort intrinsische statt gestreckter Rasterhoehe und binden denselben `aria-expanded`-/`aria-controls`-Schalter an den vollstaendigen Inhaltscontainer. Interaktionstests decken beide Kartentypen ab; der Layouttest prueft alle neun konkreten Instanzen, Titel und die Collapsed-Geometrie. |
+| Eine feste Rasterspan-Anzahl kann bei wechselnder Dashboardbreite und unterschiedlich langen Environment-Werten erneut Leerraum oder Ueberlauf erzeugen; rein automatische Tracks ohne Mindestmass koennten dagegen die quadratische Grundgeometrie aufloesen. | Die responsive Spaltenzahl weiterhin in eine gemeinsame Mindest-Rastereinheit uebersetzen, `grid-auto-rows` jedoch als `minmax(Mindestmass, auto)` definieren. Inhaltskarten erhalten `min-content` als Untergrenze; nur die datenreiche Resilience-Kachel hebt ihr bevorzugtes Quadratverhaeltnis auf. |
+| Client-Info-Infopanels koennten in minimierter Ansicht erneut Balken oder weitere Inhalte zeigen, expandiert zu kompakte Zeilen verwenden oder fuer Assessment und Severity wieder auf eine abweichende Diagrammgeometrie zurueckfallen. | Minimiert strukturell nur Kopfzeile und Plus rendern. Den gemeinsamen expandierten Mengenvertrag mit 120-px-Zeilen, 72-px-Tracks, responsive gestapelter Schmalansicht und vollstaendig wachsenden Fakten anwenden. Alle neun Panelinstanzen sowie die Abwesenheit minimierter Balken und Client-Info-Donuts regressionspruefen. |
+| Eine spaetere Progressive-Disclosure-Aenderung koennte die im Zielbild permanent sichtbaren Mengenzeilen erneut ausblenden oder die beiden Verteilungen aus der rechten Donutspalte entfernen. | Kerninhalt und optionale Zusatzdetails als getrennte DOM-Bereiche rendern; nur den Zusatzbereich an `aria-expanded` binden. Hauptmatrix, rechte Rail, zwei Donutkarten und sichtbaren Kerninhalt im Pluszustand gemeinsam regressionspruefen. |
+| Eine getrennte volle Kennzahlenzeile koennte `Assessment Status` erneut in eine zweite Reihe zwingen oder bei schmalen Viewports zu kleine quadratische Zahlenkacheln erzeugen. | Kopfzone als 3:1-Raster aus Zahlenmatrix und Assessment-Donut aufbauen; bei 1100 px stapeln und die Zahlenmatrix danach auf drei beziehungsweise zwei Spalten reduzieren. Vorhandene Quadrat- und Kachelvertraege regressionspruefen. |
+| Der Client-Open-Ablauf koennte bei spaeteren Data-Hub-Aenderungen wieder implizit in Work landen oder den gewaehlten Timeslot-Scope verlieren. | Zielbereich und `openProject(project.id, scanRunIds)` gemeinsam am zentralen `onProjectSelected`-Callback halten und durch eine Quellregression auf `dashboard` sowie die unveraenderte ScanRun-Uebergabe absichern. |
+| Ein expandiertes Infopanel koennte trotz breiter interner Balkenspalte auf der kompakten Zwei-Spalten-Kartenbreite verbleiben; Inhalte wuerden dann aus der Kachel herausragen und Nachbarkacheln ueberdecken. | Expandierte Karten auf sechs Rasterspalten setzen und an 800-/560-px-Breakpoints auf die jeweils gesamte Rasterbreite reduzieren. Desktop- und Breakpoint-Spans statisch regressionspruefen; minimierte Kartenbreite nicht veraendern. |
+| Progressive Detailkarten koennten Informationen versehentlich dauerhaft verbergen, unzugaengliche Symbolschalter verwenden oder mit erfundenen Zeitreihen eine nicht vorhandene Entwicklung suggerieren. Unterschiedliche expandierte Inhaltshoehen koennten erneut ueberlappen. | Jede Karte behaelt eine sichtbare Primaermenge mit echtem proportionalem Mengenbalken und rendert den unveraenderten vollstaendigen Inhalt ueber einen beschrifteten `aria-expanded`-/`aria-controls`-Schalter. Keine Sparklines ohne historische Daten erzeugen. Inhaltsbasierte Rastertracks und eine echte Klickregression sichern Ein-/Ausblenden, Balkenwert und ueberlauffreies Wachstum. |
+| Dynamische OS-Aufzaehlungen koennen die feste 2-x-2-Quadratflaeche der Infrastructure-&-Resilience-Kachel ueberschreiten und darunterliegende Dashboardbereiche ueberdecken; eine globale Kartenvergroesserung wuerde dagegen das gesamte dichte Raster aufblaehen. | Nur die betroffene inhaltsreiche Kachel drei Rasterzeilen belegen und dort `aspect-ratio` aufheben. Vollstaendige Werte und normale Wortumbrueche beibehalten; die Ausnahme sowie die unveraenderte Faktenmatrix statisch regressionspruefen. |
+| Feste Finding-Kachelbreiten koennen an schmalen Viewports weniger Spalten ergeben; lange Titel oder zusaetzliche Kategorien koennten bei einer zugleich festgeschriebenen Hoehe abgeschnitten werden. Eine globale Badge-Regel koennte ausserdem kompakte Pathfinder-Karten unbeabsichtigt vergroessern. | Nur die Breite und Mindesthoehe der regulaeren Work-Kachel zentral festschreiben, Zeilenhoehen fuer Virtualisierung daraus ableiten und Inhalt nach unten wachsen lassen. Die semantische Badge-Matrix strikt auf direkte Work-Rasterkacheln begrenzen; Pathfinder bleibt durch fokussierte Regressionen separat abgesichert. |
+| Ein Result-DB-Export koennte nur die aktuell geladenen 50 Zeilen statt aller Filtertreffer enthalten oder bei paralleler Datenmutation Seiten aus unterschiedlichen Ergebnisstaenden vermischen. | Exportseiten mit identischem projekt-/timeslotgebundenem Filterquery deterministisch nachladen, die erwartete Gesamtzahl ueber alle Seiten konstant pruefen und bei Aenderung oder vorzeitig leerer Seite ohne Download abbrechen. Manifest und Ergebnisanzahl gemeinsam regressionspruefen. |
+| Optionale Statushinweise oder unterschiedlich lange Zahlen-/Einheitentexte koennen die Balkenbreite und Zeilenhoehe einzelner Client-Info-Karten erneut verschieben; globale Balkenregeln koennen zugleich die kompakte Resilience-Karte ueberlagern. | Statusplatz in jeder Standardzeile reservieren, Label/Track/Wert ueber feste semantische Gridspalten ausrichten und Zahlen samt Einheit ohne Umbruch gruppieren. Die Resilience-Ausnahme setzt Zeilen und Platzierung explizit zurueck; beide Geometrien werden gemeinsam regressionsgeprueft. |
| Ein formal als `released` markierter Policy-Regelkatalog enthaelt unbekannte Runtime-Enumwerte, ueberlappende Kontextselektoren, mehrdeutige Regeln oder widerspruechlich wiederverwendete Risiko-/Abhaengigkeits-IDs und erzeugt dadurch nicht reproduzierbare beziehungsweise fachlich falsche Evaluationen oder Findings. | Die zentrale Katalogvalidierung prueft Auslieferungsmechanismen, Dispositionen, Comparatorvarianten und -modi, Severity, Kontextueberlappung sowie katalogweite ID-Definitionen geschlossen und fail-closed. Jede spaetere fachliche Katalogerweiterung benoetigt positive und negative synthetische Freigaberegressionen; der produktive Katalog bleibt bis zur fachlichen Kuratierung leer. |
| Auswahl, Fokus und fachlicher Status koennen erneut farblich vermischt werden, wenn Komponenten direkt Akzent-, Fokus- oder Severitytokens fuer eine persistente Markierung verwenden. | Persistente Auswahl ausschliesslich an `--marking-color` binden und in beiden Themes auf denselben Gelbwert regressionspruefen. `--focus-ring` bleibt nur fuer Tastaturfokus; Online-, Fehler-, Workflow- und Severityfarben bleiben fachlich getrennt. |
| Einzelansichten koennten trotz flacher gemeinsamer Tokens im Hover erneut dekorative Konturen setzen oder den Standard mit lokalen Radien und Schatten umgehen. | Appweite Projektregel und Regression an die flachen `--tile-*`-Tokens binden; normale und Hover-Zustaende getrennt von Fokus, Auswahl und Statusakzenten pruefen. Lokale Kachelgeometrie bleibt unzulaessig. |
@@ -1857,6 +1948,29 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode
| 2026-09-10 | Phasen 7/13A fuer gemischte Defender-Timeslots korrigiert: Work bestimmt den Titel jedes Datensatzes anhand seiner Scannerprovenienz und des deklarativen Titel-Headers, sodass Defender-Vorkommen im gemeinsamen All-Records-Blatt die CVE statt Device-Name oder IP zeigen. Client Info behaelt bei mehreren Scannern die allgemeine Uebersicht und bietet Defender zusaetzlich als eigenen Tab mit den vorhandenen CVE-, Device- und Site-Sichten an. 19 fokussierte Dashboard-, Titel- und Graphregressionen erfolgreich. Keine API-, SQL-, Profil- oder Persistenzmigration; Phasen 7 und 13A bleiben abgeschlossen. |
| 2026-09-10 | Phase-13A-Verarbeitungsvertrag fuer Defender-Importe korrigiert: Die Kompatibilitaetspruefung verwendet nun den tatsaechlich persistierten `processedWith.profileId` statt einer eventuell abweichenden erkannten Werkzeug-ID. Dadurch werden registrierte Defender-Profile 1.0.0 als aktuell bewertet; unbekannte Profil-/Versionspaare bleiben fail closed. Die Korrektur ist read-only fuer vorhandene Importdaten und benoetigt keinen Reimport oder Datenbankeingriff. 17 fokussierte Import-/Kompatibilitaetstests sowie der Gesamtlauf mit 766 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich; Phase 13A bleibt abgeschlossen. |
| 2026-09-10 | Microsoft Defender for IoT vulnerability imports and views umgesetzt: Profil und Source Extractor 1.0.0 erweitern die generische Excel-/CSV-Pipeline; Device-Identitaeten, CVE-Definitionen, Device-mal-CVE-Vorkommen, rohe Sensorbeobachtungen und Aggregate-only-Zahlen bleiben getrennt. Client Info bietet CVE-, Device- und Site-Sichten mit Evidenz- und Reconciliation-Drill-down. Summary-only-Quellen bleiben ohne erfundene Findings viewable. 33 fokussierte synthetische Tests sowie 764 Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL- oder Persistenzmigration; Phasen 6, 7 und 13A bleiben abgeschlossen. |
+| 2026-09-03 | Phase-7-Client-Info-Standardansicht nach Nutzerreferenz festgelegt: `Assessment Status` startet als einzige geoeffnete Informationskarte; Directory Coverage, Certificates & PKI, Infrastructure Details, Identity & Privilege, GPO & Password Hygiene, Control Paths & Trusts, Infrastructure & Resilience, Severity Distribution und Directory Overview starten minimiert und vollbreit. Alle Karten bleiben ueber die gemeinsamen Dreiecke individuell schaltbar. 15 fokussierte Dashboard-/Interaktions-/Dreieckstests und Client-/Server-Produktionsbuild erfolgreich. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase-7-Client-Info-Detailkorrektur umgesetzt: minimierte Informationskarten behalten mit voller Spaltenbreite dieselbe Breite wie im maximierten Zustand; Collapse reduziert nur die Hoehe. Der PingCastle-Engine-Hinweis wurde aus `Directory Overview` entfernt, ohne die normalisierte Quellprovenienz zu veraendern. 13 fokussierte Dashboard-/Interaktionstests und Client-/Server-Produktionsbuild erfolgreich. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase-7-Client-Info auf stabile Spalten und eine geschlossene Kopfzone korrigiert. Das laufzeitgemessene dichte Masonry wurde durch drei feste, semantisch zugeordnete Kartenstapel mit 3/2/2 Karten ersetzt; minimierte und maximierte Karten bleiben dadurch immer in ihrer Spalte und nur nachfolgende Karten derselben Spalte ruecken auf. Die sechs KPI-Kacheln fuellen auf Desktop gemeinsam die Hoehe von `Assessment Status`, sind groesser typografiert und folgen nun Compliance Score, Deviation, High Severity, Passed, Typed Observations, Directory Sections. Compliance ist als H1 hervorgehoben; ausschliesslich Deviation und High Severity sind klickbar. 15 fokussierte Dashboard-/Interaktions-/Dreieckstests, Client-/Server-Produktionsbuild, Local-only- und Designpruefung erfolgreich. Im Gesamtlauf bestanden 780 Tests; eine unabhaengige statische Data-Hub-Open-Pruefung erwartet noch die alte einzeilige Quelltextdarstellung der weiterhin korrekt vorhandenen `dashboard`-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase-7-Client-Info-Collapse geometrisch korrigiert und Plus/Minus durch Standarddreiecke ersetzt. Ein eigener `DashboardMasonryGrid` misst die zehn Karten, aktualisiert ihre Rasterspannen per ResizeObserver und packt sie dicht; dadurch rueckt die naechste Karte nach dem Schliessen sofort direkt unter die verkleinerte Kopfzeile. Vor erfolgreicher Messung beziehungsweise ohne ResizeObserver bleibt das normale sichere Grid aktiv. Beide gemeinsamen Kartentypen zeigen nun das App-weite SVG-Dreieck nach unten fuer offen und nach rechts fuer geschlossen. 16 fokussierte synthetische Dashboard-/Interaktions-/Masonry-/Icon-Tests, Client-/Server-Produktionsbuild, Local-only- und Designpruefung erfolgreich. Im Gesamtlauf bestanden 781 Tests; eine unabhaengige statische Data-Hub-Open-Pruefung erwartet noch eine alte einzeilige Quelltextdarstellung der weiterhin korrekt vorhandenen `dashboard`-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase 13B um die konkrete GPO-Sicht in Work und Result DB erweitert. Aktuelle Policy-Beobachtungen werden ohne Datenkopie aus Artefakt-, Processing-, Backup- und Identity-Persistenz als `policy-observation` projiziert, ueber `assessmentIds` demselben fachlichen Timeslot wie die Scannerlaeufe zugeordnet und mit Werten, technischen Identitaeten, Scope, Delivery Mechanism, Diagnosen und Quell-Locator exportierbar gemacht. Work besitzt ein eigenes Blatt `Group Policy · Observations` und fuehrt die Zeilen zusaetzlich in `All Records` mit `Source: Scan = Group Policy`; die Result DB zeigt sie unter dem Standardfilter als Kontext mit Strichen fuer IOE/Deviation. Die laufende Dummy-API wurde mit 51 GPO-Beobachtungen und zusammen 503 Resultaten im ausgewaehlten historischen Scope verifiziert. 13 fokussierte Tests, 781 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine SQL-Migration, keine Mutation der Dummy- oder Originaldaten; bestaetigte GPO-Findings bleiben weiterhin von Environment Profile, Identity-/Baseline-/Regelkatalog und Finding Factory abhaengig. |
+| 2026-09-03 | Phase-7-Client-Info-Faktenblock auf Nutzerwunsch als eigene Kachel umgesetzt. `Infrastructure & Resilience` zeigt nur noch seine Risiko-/Mengenwerte; die neue minimierbare Kachel `Infrastructure Details` enthaelt `Marked findings` und alle sieben bestehenden Environment-Fakten in der vollstaendigen responsiven Faktenliste. Der gemeinsame Kartenvertrag wurde fuer eine titel-only Kopfzeile optional erweitert; die Ansicht besitzt nun zehn Informationskacheln. 13 fokussierte Dashboard-/Interaktionstests, Local-only- und Designpruefung erfolgreich. Der vollstaendige TypeScript-Build bleibt durch eine unabhaengige parallel hinzugekommene GPO-Testfixture ohne `ImportProcessorReference.kind` blockiert; der nachgelagerte direkte Vite-Build konnte wegen Sandbox-`spawn EPERM` nicht separat ausgefuehrt werden. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase-7-Maester-Fehlermeldungen lesbar strukturiert. Ein neuer reiner Parser erkennt ausschliesslich eindeutige `Invoke-MgGraphRequest`-Ausfuehrungsfehler, extrahiert Graph-Meldung, Fehlercode, HTTP-Status, Methode/Endpunkt, Skriptzeile, Zeit und Korrelations-IDs und bewahrt den unveraenderten Rohtext. Das Results-Fenster zeigt die Ursache prominent, technische Werte in einer responsiven Feldmatrix und den Rohbeleg standardmaessig eingeklappt; normale Resultate bleiben unveraendert. 48 fokussierte synthetische Result-/Reader-Tests, Client-/Server-Produktionsbuild, Local-only- und Designpruefung erfolgreich. Im Gesamtlauf bestanden 777 Tests; eine unabhaengige statische Result-DB-Scope-Regression ist aufgrund einer parallel vorhandenen `assessmentIds`-Quelltextergaenzung rot, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase-7-Client-Info-Minimierung korrigiert und alle neun Informationskacheln geprueft. Die sechs Mengen-/Faktenkarten und die drei Karten der rechten beziehungsweise oberen Donut-/Faktenzone starten vollstaendig sichtbar mit Minus; ein Klick reduziert jede Karte auf die reine Kopfzeile mit Plus und intrinsischer Kopfzeilenhoehe, ein weiterer stellt den vollstaendigen Inhalt wieder her. Damit bleibt eine minimierte Karte auch neben einer hoeheren geoeffneten Rasterkarte nicht als leere Vollhoehenflaeche stehen. Beide gemeinsamen Kartenkomponenten verwenden denselben zugaenglichen Inhaltscontainer, die sechs reinen Zahlenkacheln bleiben unveraendert. 13 fokussierte Dashboard-/Interaktionstests, 776 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Ausschliesslich synthetische Testdaten verwendet; keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung. Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase 13B um die erreichbare GPO-Analyse im Data-Hub-Clientdetail erweitert. Erfolgreiche GPO-Zeilen zeigen statt einer ausgegrauten Scanner-Checkbox eine eigenstaendige GPO-Markierung und `View`; die Aktion oeffnet die vorhandene projektgebundene Workflow-, Summary-, Historien- und Review-Oberflaeche und bietet den Rueckweg zu den Clientinformationen. Der Scanner-Provenienzfilter bleibt unveraendert scannerbezogen. Am freigegebenen Dummy-Client wurde die Anzeige mit einem vollstaendig verarbeiteten Drei-GPO-Paket, 51 Beobachtungen und 48 aktuellen Review-Eintraegen inhaltsbezogen verifiziert. Sieben fokussierte Tests, 775 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt in Arbeit. |
+| 2026-09-03 | Phase 13B um die fehlende Data-Hub-Sichtbarkeit und den direkten ZIP-Auswahlweg fuer GPO-Backups ergaenzt. GPO-Artefakte erscheinen nun als eigene Quellenzeilen im zugeordneten Timeslot, fliessen in dessen Zaehler ein, zeigen ihren technischen Verarbeitungszustand und bieten bei Dead Letter Wiederholung beziehungsweise Loeschung. Ein `assessor:gpo-changed`-Refresh macht neue Einreichungen unmittelbar sichtbar. Die getrennten Buttons `Import GPO Folder` und `Import GPO ZIP` fuehren normalen Ordner beziehungsweise vorhandenes Archiv derselben bestehenden Backend-Ingestion zu; der Ordner wird zuvor weiterhin lokal deterministisch verpackt. 14 fokussierte Tests, 774 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL-, Persistenz- oder Realdatenaenderung; Phase 13B bleibt in Arbeit. |
+| 2026-09-03 | Phase 13B um die Betriebsgrenze fuer kuratierte Policy-Regelkataloge erweitert: optionale lokale JSON-Datei mit verpflichtendem SHA-256-Pin, 5-MiB-Limit, Regular-file-/Symlink-Schutz, fataler UTF-8-/JSON-Pruefung und bestehender geschlossener fachlicher Freigabevalidierung. Ungueltige oder unvollstaendige Konfiguration stoppt vor Repository- und Serverstart; ohne Datei bleibt der fachlich leere sichere Katalog aktiv. Konfiguration in `docs/LOCAL_BACKEND.md` dokumentiert. Drei neue synthetische Loaderregressionen, 28 fokussierte Tests und Gesamtlauf mit 773 bestandenen sowie 8 uebersprungenen optionalen PostgreSQL-Tests erfolgreich; Local-only-, Designpruefung und Client-/Serverbuild gruen. Keine Netzwerk-, API-, SQL-, Persistenz- oder Realdatenaenderung; Phase 13B bleibt bis zur fachlichen Regel- und Inbox-ADMX-/ADML-Kuratierung in Arbeit. |
+| 2026-09-03 | Phase 13B um snapshotbezogene Ergebnisdeduplizierung erweitert: Das additive `current`-Readmodell verfolgt die aktive Profil-/Identity-/Aggregation-/Evaluation-/Finding-Kette, waehrend `summary`, Evaluationen und Reviewdaten der vollstaendigen Audit-Historie erhalten bleiben. Die sichtbare Summary und Current Review Queue nutzen nur den aktiven Zustand; die Evaluation History bleibt separat sichtbar. Evaluate- und Finding-Aktionen fuer veraltete Ketten werden nicht mehr angeboten. Drei Domainregressionen sowie Panel-, Actions- und HTTP-Regression erfolgreich; Gesamtlauf 770 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine SQL- oder Persistenzaenderung, keine Realdaten gelesen; Phase 13B bleibt in Arbeit. |
+| 2026-09-03 | Phase-7-Client-Info-Infopanels auf die abschliessend bestaetigte Bildreferenz korrigiert: Minimiert enthalten alle neun Panels nur die luftige Kopfzeile mit `Titel — Primaermenge` und Plus, ohne Balken. Expandiert zeigen Mengenbereiche 120-px-Datenzeilen mit 72-px-dicken Mengenbalken; Assessment Status und Severity Distribution wurden von Donuts auf dieselbe Balkenkomponente umgestellt, wobei ihre Filteraktionen erhalten bleiben. Faktenzeilen wachsen mit 72-px-Mindesthoehe, die kompakte Resilience-Ausnahme wurde entfernt und schmale Ansichten stapeln Wert und 44-px-Balken responsiv. Die sechs Zahlenkacheln blieben unveraendert. 12 fokussierte Tests, 774 bestandene Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase-7-Client-Info abschliessend an die neue Gesamtansicht angepasst: sechs unveraenderte Zahlenkacheln oben, darunter sechs dauerhaft sichtbare Mengenpanels als dreispaltige Matrix und rechts eine eigene Rail mit Assessment-/Severity-Donuts sowie Directory Overview. Plus/Minus blendet nur Zusatzinformationen ein; die Kernzeilen bleiben sichtbar. Die Mengenzeilen entsprechen mit 64-px-Zeilen und 30-px-Balken der kompakten Bildgeometrie, nutzen reale Werte und behalten bestehende Filteraktionen der Donutlegenden. Responsive Breakpoints reduzieren die Matrix auf zwei/eine Spalte und stapeln die Rail. 12 fokussierte Tests, 774 bestandene Standardtests, 8 optionale PostgreSQL-Tests uebersprungen, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase-7-Client-Info-Kopfzeile verdichtet: Die sechs quadratischen Zahlenkacheln belegen als verkleinerte Sechserspur die linken drei Viertel; die Assessment-Status-Donutkarte steht im rechten Viertel derselben ersten Reihe. Severity Distribution und Directory Overview ruecken dadurch in der rechten Rail nach oben. Die Kopfzone stapelt sich ab 1100 px; die Kennzahlen wechseln dort auf drei und ab 800 px auf zwei Spalten. 12 fokussierte Layout-/Interaktionstests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Standardziel von `Open Client` in Phase 7 von Work auf Client Info umgestellt. Der zentrale Data-Hub-Auswahlcallback aktiviert `dashboard` und oeffnet weiterhin exakt das gewaehlte Projekt mit denselben ScanRun-IDs; dadurch gilt die Aenderung sowohl fuer Quick Open als auch fuer Open aus der Clientdetailseite. Neun fokussierte Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Sichtbare Phase-7-Breitenabweichung der expandierten Client-Info-Karten korrigiert: Statt auf der minimierten Zwei-Spalten-Breite zu bleiben, belegen geoeffnete Panels nun sechs Rasterspalten; bei 800 beziehungsweise 560 px wechseln sie auf die gesamte verfuegbare Vier- beziehungsweise Zwei-Spalten-Breite. Dadurch liegen Label/Wert und der 72-px-Mengenbalken wie in der Referenz nebeneinander innerhalb der Karte, ohne Nachbarflaechen zu ueberdecken. Bereits im Kopf dargestellte Primaerwerte sind aus den expandierten Zeilen entfernt; neutrale Serien folgen der roten, orangen, gelben und violetten Referenzfolge, waehrend bestehende Fachfarbgruppen unveraendert bleiben. 12 fokussierte Layout-/Interaktionstests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase-7-Client-Info nach freigegebenem Telemetrieentwurf auf Progressive Disclosure umgestellt: Die sechs Zahlenkacheln sind unveraendert. Assessment Status, Severity Distribution, Directory Overview, Directory Coverage, Identity & Privilege, Control Paths & Trusts, Certificates & PKI, GPO & Password Hygiene sowie Infrastructure & Resilience starten kompakt mit ihrer realen Primaermenge und einem Mengenbalken. Plus/Minus blendet pro Karte die vollstaendigen bestehenden Donut-, Mengenbalken- und Fakteninformationen ein beziehungsweise aus; es wurden keine im Mockup erfundenen Bereiche oder Verlaufsdaten implementiert. 15 fokussierte Dashboard-/Interaktions-/Inset-Tests, 774 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Unmittelbare Phase-7-Nutzerkorrektur fuer echte responsive Kartenhoehen: Die zuvor gesetzten drei festen Rasterzeilen wurden wieder entfernt. Breakpointabhaengige Rastereinheiten bilden nun nur noch die Mindesthoehe; `minmax(..., auto)` und `min-content` lassen Inhaltskarten anhand ihrer vollstaendigen Werte wachsen. `Infrastructure & Resilience` verwendet automatische Inhaltshoehe, waehrend andere Karten quadratisch bleiben, solange ihr Inhalt hineinpasst. 14 fokussierte Dashboard-/Inset-Tests, 770 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase-7-Infrastructure-&-Resilience-Kachel gegen Inhaltsueberlauf korrigiert: Die Karte reserviert nun drei Rasterzeilen und hebt nur fuer diese inhaltsreiche Ausnahme das starre Quadratverhaeltnis auf. Damit bleiben auch lange vollstaendige OS-Aufzaehlungen innerhalb der Flaeche, waehrend Faktenlayout und alle uebrigen quadratischen Karten unveraendert bleiben. 14 fokussierte Dashboard-/Inset-Tests, 769 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase-7-Work-Finding-Kacheln auf das bestaetigte Referenzformat vereinheitlicht: 358 px feste Breite, 223 px Mindesthoehe, keine Restbreitenstreckung und weiterhin wachsender Inhalt. Kopfaufteilung mit Hexagon links sowie Bookmark/Results rechts bleibt erhalten; die Metadaten stehen stabil als Status, Kategorie, Severity plus Weight und Score. Die Regel ist auf direkte Work-Rasterkacheln begrenzt, sodass Pathfinder-Micro-Cards kompakt bleiben. 16 fokussierte Kachel-/Typografie-/Pathfinder-Tests, 768 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase-7-Result-DB auf `Deviation = Yes` als initialen und Reset-Filter gestellt und gefilterten JSONL-Export ergaenzt. Der Button laedt alle Treffer des aktuellen Projekt-/Timeslot- und Nutzerfilterzustands in stabilen 1.000er-Seiten, bricht bei veraenderter Gesamtmenge fail-closed ab und erzeugt ein versioniertes Manifest plus eine vollstaendige JSON-Zeile je Unified Result. Drei fokussierte Export-/Scope-Tests, 767 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL-, Persistenz- oder Realdatenaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-03 | Phase-7-Client-Info-Balkenlisten bereinigt: Label, Balken und Wert verwenden nun ein identisches Dreispaltenraster; eine kompakte zweite Wertzeile ist auch ohne Hinweis reserviert, sodass `Restricted` keine einzelnen Zeilen mehr verschiebt. Zahl und optionale Einheit sind getrennt formatiert und bleiben rechtsbuendig zusammen. Die Resilience-Kompaktkarte setzt die Standardplatzierung explizit auf ihr Einspaltenlayout zurueck. 13 fokussierte Dashboard-/Kacheltests, 767 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-26 | Phase-13B-Regelkatalog-Freigabegrenze gehaertet: Runtimevalidierung fuer geschlossene Auslieferungsmechanismen, Baseline-Dispositionen, Comparatorvarianten/-modi und Severitywerte ergaenzt; ueberlappende Selektoren, mehrdeutige kontextspezifische Regeln sowie widerspruechliche Risiko- und Abhaengigkeitsdefinitionen werden vor Serviceaktivierung fail-closed abgelehnt. Der fachliche Produktivkatalog bleibt bewusst leer. Der lokale private Artefaktspeicher zeigt wieder auf den aktuellen LocalAppData-Pfad ausserhalb des Webroots; Backend `ok`, App HTTP 200 und vorhandener Speicherroot wurden ohne Inhaltszugriff bestaetigt. Neun neue synthetische Katalogtests, 25 fokussierte GPO-/Katalogtests, 764 bestandene Standardtests, 8 erwartungsgemaess uebersprungene optionale PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt in Arbeit. |
| 2026-08-25 | Phase-7-Markierungsfarbe appweit auf Gelb vereinheitlicht: Der neue Theme-Token `--marking-color` traegt in Dark und Light denselben Wert und steuert Kachelauswahl, allgemeine Auswahlrahmen/-marker, gemerkte Eintraege und Graphauswahl. Die violette Datahub-Auswahlkontur entfaellt. Tastaturfokus bleibt blau, Scanner-/Workflow-/Severitystatus behalten ihre fachlichen Farben. Projektregel und Kachelregression wurden aktualisiert. 24 fokussierte Auswahl-/Dashboard-/Graphtests, Designcheck und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-08-25 | Phase-7-Kachelstandard appweit auf die freigegebene flache Client-Info-Geometrie umgestellt: `--tile-border` ist in beiden Themes transparent, `--tile-radius` verwendet den zentralen Nullradius und `--tile-card-shadow` ist deaktiviert. Datahub-, Dashboard-, Sidebar-, Work- und Pathfinder-Hover veraendern die Flaeche ohne dekorative Kontur; Fokus, Auswahl und Statusmarkierungen bleiben sichtbar. `AGENTS.md` und die gemeinsamen Kachelregressionen wurden auf den neuen verbindlichen Standard aktualisiert. 24 fokussierte Kachel-/Dashboardtests, Designcheck und Client-Produktionsbuild erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
diff --git a/docs/LOCAL_BACKEND.md b/docs/LOCAL_BACKEND.md
index c7ca8f7..b0815ff 100644
--- a/docs/LOCAL_BACKEND.md
+++ b/docs/LOCAL_BACKEND.md
@@ -80,6 +80,26 @@ Start ab; es findet kein stiller Fallback statt.
Ein vollständiges lokales PostgreSQL-Setup, Schema-, Migrations-, Backup- und
Restore-Regeln stehen in `docs/POSTGRESQL.md`.
+## Kuratierter GPO-Regelkatalog
+
+Ohne weitere Konfiguration startet die Policy-Evaluation mit dem freigegebenen,
+fachlich leeren Katalog. Ein lokal kuratierter JSON-Katalog wird nur geladen,
+wenn Pfad und erwarteter SHA-256 gemeinsam gesetzt sind:
+
+```text
+ASSESSOR_POLICY_RULE_CATALOG_PATH=C:\geschuetzter-pfad\policy-rules.json
+ASSESSOR_POLICY_RULE_CATALOG_SHA256=<64-stelliger SHA-256-Hexwert>
+```
+
+Der Server lädt höchstens 5 MiB aus einer regulären Datei, vergleicht den
+Inhalt vor dem JSON-Parsing mit dem fest konfigurierten Hash und validiert den
+vollständigen Katalogvertrag einschließlich Kontextüberschneidungen,
+Comparatoren, Risiko- und Abhängigkeitsregeln. Fehlende Paarparameter,
+Hashabweichungen, Symlinks, ungültiges UTF-8/JSON oder fachlich ungültige Regeln
+verhindern den Serverstart. Die Datei wird weder aus dem Netzwerk bezogen noch
+durch die Anwendung verändert. Jeder Evaluation Run speichert weiterhin den
+tatsächlich verwendeten vollständigen Katalog für reproduzierbares Reprocessing.
+
Originaldateien werden aktuell nicht als separate Serverartefakte abgelegt. Die
API verarbeitet die Bytes und speichert die daraus erzeugten kanonischen
Fachobjekte. Eine spätere Aufbewahrung von Originalartefakten bleibt eine eigene
diff --git a/docs/architecture/gpo-threat-model.md b/docs/architecture/gpo-threat-model.md
index a4c297b..b5dbd21 100644
--- a/docs/architecture/gpo-threat-model.md
+++ b/docs/architecture/gpo-threat-model.md
@@ -36,6 +36,7 @@ Ein Parserworker begrenzt Zeit und Speicher, isoliert aber keinen bösartigen na
| Skript- oder Binärausführung | Nur inventarisieren und hashen; niemals importieren, laden, entschlüsseln oder starten. |
| Manipulierte oder herstellerspezifisch erweiterte `Registry.pol`-Datensaetze erzeugen falsche Instruktionen oder Ressourcenverbrauch. | PReg-Signatur und Version, Feldabschluesse, Schluessel und Wertnamen, Typen, Datengroessen, Datensatzanzahl und Gesamtgroesse vor Reduktion begrenzen; nur freigegebene Typen und REG_NONE als exakt leere Schluesselanlage akzeptieren, sonst das Artefakt ohne Salvage blockieren. Keine Datei ausfuehren und keinen externen Prozess starten. |
| GPP-`cpassword` oder andere Geheimnisse | Nur Vorhandensein und Locator erfassen; Wert bereits an der Parsergrenze maskieren, niemals entschlüsseln, loggen oder exportieren. |
+| Manipulierter oder unbeabsichtigt ausgetauschter Policy-Regelkatalog | Einen extern kuratierten Katalog nur aus einer lokalen regulären Nicht-Symlink-Datei bis 5 MiB laden, wenn Pfad und erwarteter SHA-256 gemeinsam konfiguriert sind. Hash vor UTF-8-/JSON-Parsing prüfen, danach den vollständigen fachlichen Katalogvertrag fail-closed validieren und bei jeder Abweichung vor Repository- und Serverstart abbrechen. Keine automatische Netzwerkquelle oder stille Aktivierung. |
| Pfad-/Namensheuristik erzeugt falsche Policy- oder Zielidentität | Technische IDs ausschließlich aus unterstützten Artefaktinhalten und versionierten Regeln; Namen und Pfade bleiben Provenienz. |
| Historische Backups werden gemeinsam aggregiert | Explizite Backup-GUID, GPO-GUID, Domänenidentität, manifestgestützte Set-ID und Erhebungsfenster prüfen; doppelte GPOs, Zeitkonflikte und Domänenmischung blockieren. |
| Ausgewählte Teilmenge wird als vollständige Umgebung bewertet | Setvollständigkeit getrennt von Instanzvollständigkeit modellieren; negative Schlussfolgerungen nur bei manifestgestütztem vollständigem Set mit erwarteter und beobachteter Anzahl. |
diff --git a/server/assessor-http-server.ts b/server/assessor-http-server.ts
index e66e273..27e17df 100644
--- a/server/assessor-http-server.ts
+++ b/server/assessor-http-server.ts
@@ -235,6 +235,7 @@ function unifiedQueryFrom(url: URL): UnifiedResultQuery {
return {
projectId: url.searchParams.get('projectId') ?? undefined,
assessmentId: url.searchParams.get('assessmentId') ?? undefined,
+ assessmentIds: many('assessmentIds'),
scanRunId: url.searchParams.get('scanRunId') ?? undefined,
scanRunIds: many('scanRunIds'),
evaluationRunId: url.searchParams.get('evaluationRunId') ?? undefined,
diff --git a/server/gpo/policy-evaluation-rule-catalog-loader.ts b/server/gpo/policy-evaluation-rule-catalog-loader.ts
new file mode 100644
index 0000000..356187b
--- /dev/null
+++ b/server/gpo/policy-evaluation-rule-catalog-loader.ts
@@ -0,0 +1,87 @@
+import { createHash, timingSafeEqual } from 'node:crypto';
+import { lstat, readFile } from 'node:fs/promises';
+import { resolve } from 'node:path';
+import {
+ RELEASED_POLICY_EVALUATION_RULE_CATALOG,
+ policyEvaluationRuleCatalogValidationErrors,
+ type PolicyEvaluationRuleCatalog
+} from '../../src/domain/policy-evaluation-rules';
+
+export const MAXIMUM_POLICY_RULE_CATALOG_BYTES = 5 * 1024 * 1024;
+
+export interface PolicyEvaluationRuleCatalogLoadOptions {
+ path?: string;
+ expectedSha256?: string;
+ maximumBytes?: number;
+}
+
+function isObject(value: unknown): value is Record {
+ return typeof value === 'object' && value !== null && !Array.isArray(value);
+}
+
+function hasValidationShape(value: unknown): value is PolicyEvaluationRuleCatalog {
+ if (!isObject(value) || !isObject(value.catalog) || !Array.isArray(value.rules)) return false;
+ return value.rules.every(rule => isObject(rule)
+ && Array.isArray(rule.contexts)
+ && rule.contexts.every(context => isObject(context)
+ && Array.isArray(context.roles) && Array.isArray(context.scopes))
+ && Array.isArray(rule.dependencies)
+ && rule.dependencies.every(isObject)
+ && (rule.comparator === undefined || isObject(rule.comparator))
+ && (rule.riskRule === undefined || isObject(rule.riskRule)));
+}
+
+function normalizedSha256(value: string | undefined): string | undefined {
+ const normalized = value?.trim().toLowerCase();
+ if (!normalized) return undefined;
+ if (!/^[a-f0-9]{64}$/.test(normalized)) {
+ throw new Error('ASSESSOR_POLICY_RULE_CATALOG_SHA256 muss ein SHA-256-Hexwert sein.');
+ }
+ return normalized;
+}
+
+export async function loadPolicyEvaluationRuleCatalog(
+ options: PolicyEvaluationRuleCatalogLoadOptions = {}
+): Promise {
+ const configuredPath = options.path?.trim();
+ const expectedSha256 = normalizedSha256(options.expectedSha256);
+ if (!configuredPath && !expectedSha256) return structuredClone(RELEASED_POLICY_EVALUATION_RULE_CATALOG);
+ if (!configuredPath || !expectedSha256) {
+ throw new Error('Policy-Regelkatalogpfad und SHA-256 muessen gemeinsam konfiguriert werden.');
+ }
+ const maximumBytes = options.maximumBytes ?? MAXIMUM_POLICY_RULE_CATALOG_BYTES;
+ if (!Number.isSafeInteger(maximumBytes) || maximumBytes < 1 || maximumBytes > MAXIMUM_POLICY_RULE_CATALOG_BYTES) {
+ throw new Error('Die Groessengrenze des Policy-Regelkatalogs ist ungueltig.');
+ }
+
+ const absolutePath = resolve(configuredPath);
+ const information = await lstat(absolutePath);
+ if (information.isSymbolicLink() || !information.isFile()) {
+ throw new Error('Der Policy-Regelkatalog muss eine regulaere Datei sein.');
+ }
+ if (information.size < 1 || information.size > maximumBytes) {
+ throw new Error('Der Policy-Regelkatalog verletzt die konfigurierte Groessengrenze.');
+ }
+ const bytes = await readFile(absolutePath);
+ if (bytes.byteLength !== information.size || bytes.byteLength > maximumBytes) {
+ throw new Error('Der Policy-Regelkatalog wurde waehrend des Lesens veraendert oder ist zu gross.');
+ }
+ const actualSha256 = createHash('sha256').update(bytes).digest('hex');
+ if (!timingSafeEqual(Buffer.from(actualSha256, 'hex'), Buffer.from(expectedSha256, 'hex'))) {
+ throw new Error('Der Policy-Regelkatalog stimmt nicht mit dem konfigurierten SHA-256 ueberein.');
+ }
+
+ let parsed: unknown;
+ try {
+ const text = new TextDecoder('utf-8', { fatal: true }).decode(bytes).replace(/^\uFEFF/, '');
+ parsed = JSON.parse(text);
+ } catch {
+ throw new Error('Der Policy-Regelkatalog ist kein gueltiges UTF-8-JSON-Dokument.');
+ }
+ if (!hasValidationShape(parsed)) {
+ throw new Error('Der Policy-Regelkatalog besitzt keine gueltige Struktur.');
+ }
+ const errors = policyEvaluationRuleCatalogValidationErrors(parsed);
+ if (errors.length) throw new Error(`Der Policy-Regelkatalog wurde abgelehnt: ${errors.join(' ')}`);
+ return structuredClone(parsed);
+}
diff --git a/server/gpo/zip-inventory.ts b/server/gpo/zip-inventory.ts
index 8833a46..b3b4cf2 100644
--- a/server/gpo/zip-inventory.ts
+++ b/server/gpo/zip-inventory.ts
@@ -369,4 +369,4 @@ export function readVerifiedZipFiles(
selected.push({ entry, bytes: content.slice() });
});
return selected.sort((left, right) => left.entry.index - right.entry.index);
-}
\ No newline at end of file
+}
diff --git a/server/index.ts b/server/index.ts
index db78ca3..0d9d2da 100644
--- a/server/index.ts
+++ b/server/index.ts
@@ -17,6 +17,7 @@ import { GpoPolicyFindingService } from './gpo/gpo-policy-finding-service';
import { GpoPolicyAnalysisOverviewService } from './gpo/gpo-policy-analysis-overview-service';
import { NvdCveClient } from './cve/nvd-cve-client';
import { CveEnrichmentService } from './cve/cve-enrichment-service';
+import { loadPolicyEvaluationRuleCatalog } from './gpo/policy-evaluation-rule-catalog-loader';
function boundedInteger(value: string | undefined, fallback: number, minimum: number, maximum: number, name: string): number {
if (value === undefined || value.trim() === '') return fallback;
@@ -52,6 +53,10 @@ async function main(): Promise {
maximumOldGenerationMb: boundedInteger(process.env.ASSESSOR_GPO_MEMORY_MB, 1_024, 256, 2_048, 'ASSESSOR_GPO_MEMORY_MB'),
maximumYoungGenerationMb: boundedInteger(process.env.ASSESSOR_GPO_YOUNG_MEMORY_MB, 128, 64, 512, 'ASSESSOR_GPO_YOUNG_MEMORY_MB')
});
+ const policyEvaluationRuleCatalog = await loadPolicyEvaluationRuleCatalog({
+ path: process.env.ASSESSOR_POLICY_RULE_CATALOG_PATH,
+ expectedSha256: process.env.ASSESSOR_POLICY_RULE_CATALOG_SHA256
+ });
const runtime = await createRepositoryRuntime();
const artifactStore = new FileSystemBackendArtifactStore(artifactRoot);
const gpoBackupSubmissionService = new GpoBackupSubmissionService(
@@ -65,7 +70,9 @@ async function main(): Promise {
runtime.repository, artifactStore, defaultImportResourcePolicy.maximumFileBytes, gpoInventoryExecutor
);
const gpoPolicySnapshotService = new GpoPolicySnapshotService(runtime.repository);
- const gpoPolicyEvaluationService = new GpoPolicyEvaluationService(runtime.repository);
+ const gpoPolicyEvaluationService = new GpoPolicyEvaluationService(runtime.repository, {
+ ruleCatalog: policyEvaluationRuleCatalog
+ });
const gpoPolicyFindingService = new GpoPolicyFindingService(runtime.repository);
const gpoPolicyAnalysisOverviewService = new GpoPolicyAnalysisOverviewService(runtime.repository);
const cveEnrichmentService = new CveEnrichmentService(runtime.repository, new NvdCveClient({
diff --git a/server/postgres/postgres-assessor-repository.ts b/server/postgres/postgres-assessor-repository.ts
index f90a0c0..892fc72 100644
--- a/server/postgres/postgres-assessor-repository.ts
+++ b/server/postgres/postgres-assessor-repository.ts
@@ -36,6 +36,7 @@ import type { DbStructureColumn, DbStructureForeignKey, DbStructureLayerId, DbSt
import { storedGpoBackupInstanceValidationErrors, storedGpoPolicyAnalysisValidationErrors } from '../../src/domain/gpo-analysis-persistence';
import {
createEnvironmentUnifiedResult,
+ createCurrentPolicyObservationUnifiedResults,
createPolicyUnifiedResult,
createScannerUnifiedResult,
deriveUnifiedResultFacets,
@@ -1077,13 +1078,36 @@ export class PostgresAssessorRepository implements AssessorRepository {
}));
}
+ private async unifiedPolicyObservationResults(
+ query: UnifiedResultQuery = {},
+ observationId?: string
+ ): Promise {
+ if (query.sourceKind?.length && !query.sourceKind.includes('policy-observation')) return [];
+ const where = query.projectId ? 'WHERE project_id = $1' : '';
+ const values = query.projectId ? [query.projectId] : [];
+ const [artifactRows, processingRows, backupRows, analysisRows] = await Promise.all([
+ this.pool.query>(`SELECT data FROM assessor_import_artifacts ${where} ORDER BY created_at, id`, values),
+ this.pool.query>(`SELECT data FROM assessor_import_processing_runs ${where} ORDER BY completed_at, id`, values),
+ this.pool.query>(`SELECT data FROM assessor_gpo_backup_instances ${where} ORDER BY created_at, id`, values),
+ this.pool.query>(`SELECT data FROM assessor_policy_identity_analysis_runs ${where} ORDER BY completed_at, id`, values)
+ ]);
+ const results = createCurrentPolicyObservationUnifiedResults(
+ dataRows(artifactRows),
+ dataRows(processingRows),
+ dataRows(backupRows),
+ dataRows(analysisRows)
+ );
+ return observationId ? results.filter(item => item.sourceResultId === observationId) : results;
+ }
+
private async allUnifiedResults(query: UnifiedResultQuery = {}): Promise {
- const [scanner, environment, policy] = await Promise.all([
+ const [scanner, environment, policyObservations, policy] = await Promise.all([
this.unifiedScannerResults(query),
this.unifiedEnvironmentResults(query),
+ this.unifiedPolicyObservationResults(query),
this.unifiedPolicyResults(query)
]);
- return [...scanner, ...environment, ...policy];
+ return [...scanner, ...environment, ...policyObservations, ...policy];
}
async queryUnifiedResults(query: UnifiedResultQuery = {}): Promise {
@@ -1097,11 +1121,14 @@ export class PostgresAssessorRepository implements AssessorRepository {
async getUnifiedResultById(resultProjectionId: string): Promise {
const scannerPrefix = 'scanner-finding:';
const policyPrefix = 'policy-evaluation:';
+ const policyObservationPrefix = 'policy-observation:';
const environmentPrefix = 'environment-observation:';
const items = resultProjectionId.startsWith(scannerPrefix)
? await this.unifiedScannerResults({}, resultProjectionId.slice(scannerPrefix.length))
: resultProjectionId.startsWith(policyPrefix)
? await this.unifiedPolicyResults({}, resultProjectionId.slice(policyPrefix.length))
+ : resultProjectionId.startsWith(policyObservationPrefix)
+ ? await this.unifiedPolicyObservationResults({}, resultProjectionId.slice(policyObservationPrefix.length))
: resultProjectionId.startsWith(environmentPrefix)
? await this.unifiedEnvironmentResults({}, resultProjectionId.slice(environmentPrefix.length))
: [];
diff --git a/src/app/App.tsx b/src/app/App.tsx
index f8b869a..5de5947 100644
--- a/src/app/App.tsx
+++ b/src/app/App.tsx
@@ -151,10 +151,26 @@ export function App() {
/>
}
{activeArea === 'graph' && dataset && !hasClientTimeslotScope &&
Backup configuration evidence only. Effective application is not verified without RSoP or GP Results.
- Counts summarize persisted run history; every evaluation remains a separate auditable record.
+ Summary and review counts represent the current active snapshot chains. Evaluation history remains auditable below.
{!hasPipelineData ?
No policy analysis runs yet
Imported GPO backups remain processing evidence until snapshot aggregation and baseline evaluation have run.
Processing readiness: {processingWarnings.map(value => `${processingStatusLabel(value.value)} (${value.count.toLocaleString('en-US')})`).join(' · ')}. Comparisons with unknown or incompatible contracts are blocked; reimport the original source with the current profile where recommended.
');
- expect(browserSource).toMatch(/scanRunIds\r?\n };/);
+ expect(browserSource).toContain('assessmentIds');
expect(browserSource).toContain('queryUnifiedResultFacets(scopedQuery)');
expect(browserSource).toContain('queryUnifiedResults({ ...scopedQuery, offset: 0, limit })');
expect(browserSource).toContain('while (loadAll && items.length < firstPage.total)');
expect(browserSource).toContain('limit: MAX_QUERY_PAGE_SIZE');
expect(browserSource).toContain('>Load more');
expect(browserSource).toContain('>Load all');
+ expect(browserSource).toContain('DEFAULT_RESULT_DB_FILTERS: UnifiedResultQuery = { deviation: true }');
+ expect(browserSource).toContain('onReset={() => updateFilters({ ...DEFAULT_RESULT_DB_FILTERS })}');
+ expect(browserSource).toContain("'Export JSONL'");
+ expect(browserSource).toContain('queryAllUnifiedResults');
+ expect(browserSource).toContain('buildUnifiedResultJsonl(scopedQuery, results, generatedAt)');
expect(browserSource).toContain("item.sourceKind === 'environment-observation'");
+ expect(browserSource).toContain("item.sourceKind === 'policy-observation'");
+ expect(browserSource).toContain('item.policyValues');
expect(browserSource).toContain('item.environmentNormalizedValue');
expect(browserSource).toContain('item.environmentOriginalValue');
expect(domainSource).toContain("query.scanRunIds.includes(item.scanRunId)");
expect(domainSource).toContain("sourceKind: 'environment-observation'");
+ expect(domainSource).toContain("sourceKind: 'policy-observation'");
expect(domainSource).toContain('environmentProperty: observation.property');
expect(serverSource).toContain("scanRunIds: many('scanRunIds')");
+ expect(serverSource).toContain("assessmentIds: many('assessmentIds')");
expect(serverSource).toContain("environmentProperty: many('environmentProperty')");
expect(postgresSource).toContain("r.id = ANY(?::text[])");
expect(postgresSource).toContain('FROM assessor_environment_observations o');
diff --git a/tests/features/tile-card.test.ts b/tests/features/tile-card.test.ts
index c70e0da..6cc30e9 100644
--- a/tests/features/tile-card.test.ts
+++ b/tests/features/tile-card.test.ts
@@ -76,6 +76,14 @@ describe('tileBadges', () => {
.toEqual(['CIS 2', 'CIS 2.2']);
});
+ it('ordnet abgeleitete Kategorien vor Severity, Weight und Score ein', () => {
+ const cisRecord: FindingRecord = { ...record, title: '2.2.2 Ensure a synthetic user right' };
+
+ expect(tileBadges(cisRecord, 'cis-cat').map(badge => badge.text)).toEqual([
+ 'IOE Found', 'Entra ID', 'CIS 2', 'CIS 2.2', 'Low', 'Weight: 2', 'Score: 86'
+ ]);
+ });
+
it('verdichtet ueberzaehlige Graphbadges zu einem sichtbaren Zaehler', () => {
const badges = [
{ label: 'Status', value: 'Fail', text: 'Fail' },
diff --git a/tests/features/tile-segment-grammar.test.ts b/tests/features/tile-segment-grammar.test.ts
index f4cc5c6..c31f167 100644
--- a/tests/features/tile-segment-grammar.test.ts
+++ b/tests/features/tile-segment-grammar.test.ts
@@ -23,7 +23,8 @@ describe('binding segment and tile grammar', () => {
'--segment-inset: var(--space-3);', '--segment-gap: var(--space-3);',
'--tile-surface:', '--tile-surface-hover:', '--tile-border:',
'--tile-selected-border: var(--marking-color);', '--tile-radius: var(--radius-sm);',
- '--tile-compact-width: 186px;', '--tile-content-width: 320px;',
+ '--tile-compact-width: 186px;', '--tile-content-width: 358px;',
+ '--tile-content-min-height: 223px;',
'--tile-card-shadow:'
]) expect(tokens).toContain(token);
@@ -58,9 +59,14 @@ describe('binding segment and tile grammar', () => {
expect(layout).toMatch(/\.tile-view-scroll\s*\{[^}]*padding:\s*var\(--panel-inset\);/s);
expect(legacy).toMatch(/\.tile-grid\s*\{[^}]*justify-content:\s*start;[^}]*border-radius:\s*var\(--segment-radius\);/s);
expect(legacy).toMatch(/\.data-tile\s*\{[^}]*border-radius:\s*var\(--tile-radius\);[^}]*box-shadow:\s*var\(--tile-card-shadow\);/s);
- expect(viewer).toContain('gridTemplateColumns: `repeat(${tileColumns}, minmax(var(--tile-content-width), 1fr))`');
+ expect(viewer).toContain('const TILE_MIN_WIDTH = 358;');
+ expect(viewer).toContain('const TILE_MIN_HEIGHT = 223;');
+ expect(viewer).toContain('gridTemplateColumns: `repeat(${tileColumns}, var(--tile-content-width))`');
expect(viewer).toContain('const TILE_GAP = 12;');
- expect(viewer).toContain('const TILE_ROW_HEIGHT = 172;');
+ expect(viewer).toContain('const TILE_ROW_HEIGHT = TILE_MIN_HEIGHT + TILE_GAP;');
+ expect(legacy).toMatch(/\.data-tile\s*\{[^}]*min-height:\s*var\(--tile-content-min-height\);/s);
+ expect(legacy).toMatch(/\.tile-grid > \.data-tile \.data-tile-badges\s*\{[^}]*display:\s*grid;[^}]*grid-template-columns:\s*max-content max-content;/s);
+ expect(legacy).toMatch(/\[data-badge-role="status"\],[\s\S]*\[data-badge-role="category"\],[\s\S]*\[data-badge-role="score"\]\s*\{[^}]*grid-column:\s*1 \/ -1;/s);
expect(policy).toContain('grid-template-columns: repeat(auto-fill, var(--tile-compact-width));');
expect(pathfinder).toMatch(/\.finding-path-card\s*\{[^}]*border-radius:\s*var\(--tile-radius\);[^}]*box-shadow:\s*var\(--tile-card-shadow\);/s);
diff --git a/tests/local-only-check.mjs b/tests/local-only-check.mjs
index 0a857b7..4730128 100644
--- a/tests/local-only-check.mjs
+++ b/tests/local-only-check.mjs
@@ -135,7 +135,10 @@ assert.match(gpoFolderTransport, /maximumZipEntries/, 'GPO folder transport must
assert.match(gpoFolderTransport, /compressionMethod|setUint16\(offset \+ 8, 0/, 'GPO folder transport must use a bounded non-compressing transport envelope');
const gpoFolderUi = read(join('src', 'features', 'project-import', 'GpoFolderImport.tsx'));
assert.match(gpoFolderUi, /webkitdirectory/, 'the Datahub GPO import must select a complete browser folder');
-assert.match(gpoFolderUi, /submitGpoBackup\(projectId, envelope, assessmentId\)/, 'the GPO folder envelope must cross the project-and-timeslot-bound API');const gpoZipInventory = read(join('server', 'gpo', 'zip-inventory.ts'));
+assert.match(gpoFolderUi, /announceSubmission\(envelope,/, 'the GPO folder envelope must enter the shared submission boundary');
+assert.match(gpoFolderUi, /submitGpoBackup\(projectId, file, assessmentId\)/, 'folder envelopes and uploaded ZIPs must cross the project-and-timeslot-bound API');
+assert.match(gpoFolderUi, /accept="\.zip,application\/zip"/, 'the Datahub GPO import must also accept an existing ZIP package');
+const gpoZipInventory = read(join('server', 'gpo', 'zip-inventory.ts'));
assert.match(gpoZipInventory, /zip-entry-crc-mismatch/, 'GPO ZIP inventory must verify actual entry CRC values');
assert.match(gpoZipInventory, /zip-nested-archive-rejected/, 'GPO ZIP inventory must reject nested archives');
assert.match(gpoZipInventory, /zip-link-rejected/, 'GPO ZIP inventory must reject symbolic links');
diff --git a/tests/server/policy-evaluation-rule-catalog-loader.test.ts b/tests/server/policy-evaluation-rule-catalog-loader.test.ts
new file mode 100644
index 0000000..dde65fb
--- /dev/null
+++ b/tests/server/policy-evaluation-rule-catalog-loader.test.ts
@@ -0,0 +1,100 @@
+import { createHash } from 'node:crypto';
+import { mkdtemp, rm, writeFile } from 'node:fs/promises';
+import { tmpdir } from 'node:os';
+import { join } from 'node:path';
+import { afterEach, describe, expect, it } from 'vitest';
+import {
+ loadPolicyEvaluationRuleCatalog,
+ MAXIMUM_POLICY_RULE_CATALOG_BYTES
+} from '../../server/gpo/policy-evaluation-rule-catalog-loader';
+import {
+ POLICY_EVALUATION_RULE_CATALOG,
+ RELEASED_POLICY_EVALUATION_RULE_CATALOG,
+ type PolicyEvaluationRuleCatalog
+} from '../../src/domain/policy-evaluation-rules';
+
+const directories: string[] = [];
+
+function syntheticCatalog(): PolicyEvaluationRuleCatalog {
+ return {
+ version: 1,
+ id: 'synthetic-curated-policy-rules-1',
+ catalog: POLICY_EVALUATION_RULE_CATALOG,
+ status: 'released',
+ rules: [{
+ version: 1,
+ id: 'synthetic-rule-1',
+ identityId: 'registry:computer:hklm:software\\policies\\synthetic:value',
+ deliveryMechanism: 'registry-policy',
+ contexts: [{
+ version: 1,
+ productFamily: 'Synthetic Windows',
+ productVersion: '1',
+ roles: ['Member Server'],
+ scopes: ['computer']
+ }],
+ baselineDisposition: 'explicit-recommendation',
+ comparator: { kind: 'equality' },
+ riskRule: { version: 1, id: 'synthetic-risk-1', severity: 'high' },
+ dependencies: []
+ }]
+ };
+}
+
+async function catalogFile(content: string): Promise<{ path: string; sha256: string }> {
+ const directory = await mkdtemp(join(tmpdir(), 'assessor-policy-catalog-'));
+ directories.push(directory);
+ const path = join(directory, 'catalog.json');
+ await writeFile(path, content, 'utf8');
+ return { path, sha256: createHash('sha256').update(content, 'utf8').digest('hex') };
+}
+
+afterEach(async () => {
+ await Promise.all(directories.splice(0).map(directory => rm(directory, { recursive: true, force: true })));
+});
+
+describe('policy evaluation rule catalog loader', () => {
+ it('keeps the safe empty released catalog when no operator file is configured', async () => {
+ const loaded = await loadPolicyEvaluationRuleCatalog();
+ expect(loaded).toEqual(RELEASED_POLICY_EVALUATION_RULE_CATALOG);
+ expect(loaded).not.toBe(RELEASED_POLICY_EVALUATION_RULE_CATALOG);
+ });
+
+ it('loads a pinned, structurally and semantically valid curated catalog', async () => {
+ const expected = syntheticCatalog();
+ const source = `\uFEFF${JSON.stringify(expected)}`;
+ const file = await catalogFile(source);
+
+ await expect(loadPolicyEvaluationRuleCatalog({
+ path: file.path,
+ expectedSha256: file.sha256
+ })).resolves.toEqual(expected);
+ });
+
+ it('fails closed for incomplete configuration, hash drift, malformed structure, and oversize input', async () => {
+ const valid = await catalogFile(JSON.stringify(syntheticCatalog()));
+ await expect(loadPolicyEvaluationRuleCatalog({ path: valid.path }))
+ .rejects.toThrow('gemeinsam konfiguriert');
+ await expect(loadPolicyEvaluationRuleCatalog({
+ path: valid.path,
+ expectedSha256: '0'.repeat(64)
+ })).rejects.toThrow('SHA-256');
+
+ const malformed = await catalogFile(JSON.stringify({ version: 1, rules: [null] }));
+ await expect(loadPolicyEvaluationRuleCatalog({
+ path: malformed.path,
+ expectedSha256: malformed.sha256
+ })).rejects.toThrow('keine gueltige Struktur');
+
+ await expect(loadPolicyEvaluationRuleCatalog({
+ path: valid.path,
+ expectedSha256: valid.sha256,
+ maximumBytes: 1
+ })).rejects.toThrow('Groessengrenze');
+ await expect(loadPolicyEvaluationRuleCatalog({
+ path: valid.path,
+ expectedSha256: valid.sha256,
+ maximumBytes: MAXIMUM_POLICY_RULE_CATALOG_BYTES + 1
+ })).rejects.toThrow('Groessengrenze');
+ });
+});
--
2.39.5
From d55a456dfef82a1d46e259dfcdb3d30c31ae8343 Mon Sep 17 00:00:00 2001
From: Michael
Date: Sun, 6 Sep 2026 20:54:33 +0200
Subject: [PATCH 08/33] GPO Implementierung Testbereit
---
AGENTS.md | 10 +-
docker-compose.postgres.yml | 4 +
docs/IMPLEMENTATION_PLAN.md | 192 +++++-
docs/RESULT_CONTRACT.md | 36 +-
docs/UNIFIED_RESULT_MODEL.md | 24 +-
docs/architecture/gpo-threat-model.md | 22 +-
.../policy-analyzer-comparison-contract.md | 42 ++
docs/architecture/public-ai-search.md | 25 +
index.html | 2 +-
package-lock.json | 4 +-
package.json | 2 +-
server/assessor-http-server.ts | 27 +-
server/gpo/advanced-audit-parser.ts | 1 +
server/gpo/gpo-automatic-analysis-service.ts | 89 +++
server/gpo/gpo-backup-ingestion.ts | 3 +-
server/gpo/gpo-backup-job-processor.ts | 11 +-
server/gpo/gpo-backup-management-service.ts | 4 +-
server/gpo/gpo-backup-submission-service.ts | 2 +-
server/gpo/gpo-environment-context.ts | 30 +
server/gpo/gpo-inventory-executor.ts | 8 +-
server/gpo/gpo-metadata-parser.ts | 70 ++-
.../gpo/gpo-policy-evaluation-rule-engine.ts | 18 +-
server/gpo/gpo-policy-evaluation-service.ts | 177 +++---
server/gpo/gpo-policy-finding-service.ts | 4 +-
server/gpo/gpo-policy-snapshot-service.ts | 7 +-
server/gpo/gpp-drive-maps.ts | 2 +-
server/gpo/gpp-local-users-groups.ts | 2 +-
server/gpo/gpp-services.ts | 2 +-
server/gpo/group-policy-preference-parser.ts | 2 +-
.../gpo/microsoft-security-baseline-parser.ts | 40 +-
server/gpo/policy-target-resolver.ts | 24 +
server/gpo/registry-policy-parser.ts | 3 +-
server/gpo/security-template-parser.ts | 1 +
server/index.ts | 5 +
server/postgres/migration-catalog.ts | 4 +
.../migrations/019_native_policy_targets.sql | 6 +
.../020_baseline_driven_policy_evaluation.sql | 30 +
.../postgres/postgres-assessor-repository.ts | 164 ++++-
src/api/assessor-api-client.ts | 18 +-
src/api/assessor-api-contract.ts | 1 +
src/app/App.tsx | 21 +-
src/app/AppProvider.tsx | 83 ++-
src/app/work-scope.ts | 10 +-
src/components/Dialog/Dialog.tsx | 7 +-
.../EmptyWorkspace/EmptyWorkspace.tsx | 5 +-
.../OperationProgress/OperationProgress.tsx | 19 +
.../PanelLoadingState/PanelLoadingState.tsx | 14 +
src/components/PathText/PathText.tsx | 30 +
.../RichTextValue/RichTextValue.tsx | 9 +-
src/components/TileCard/TileCard.tsx | 13 +-
src/domain/assessor-release.ts | 3 +
src/domain/canonical-model.ts | 2 +
src/domain/dataset.ts | 2 +
src/domain/deviation-predicate.ts | 3 +
src/domain/finding.ts | 5 +-
src/domain/gpo-metadata.ts | 2 +-
src/domain/gpo-policy-identity.ts | 23 +-
src/domain/gpo-snapshot-aggregation.ts | 9 +-
src/domain/ingestion-persistence.ts | 1 +
.../microsoft-security-baseline-analysis.ts | 10 +-
src/domain/policy-analysis-overview.ts | 6 +-
src/domain/policy-comparison-disposition.ts | 14 +
src/domain/policy-evaluation.ts | 22 +-
src/domain/result-contract-mapping.ts | 7 +-
.../result-db-supplemental-disclosure.ts | 134 ++++
src/domain/unified-result.ts | 230 ++++++-
src/evaluation/policy-comparator.ts | 4 +
src/evaluation/policy-work-results.ts | 126 ++++
src/exports/unified-result-jsonl.ts | 21 +-
src/features/about/AboutDialog.tsx | 70 +++
src/features/dashboard/DashboardPanel.tsx | 19 +-
.../db-structure/DbStructurePanel.tsx | 124 +++-
src/features/finding-reader/FindingReader.tsx | 47 +-
.../import-workflow/ImportWorkflowDialog.tsx | 5 +-
src/features/linked-results/LinkedResults.tsx | 7 +-
.../linked-results/inline-result-tables.ts | 3 +-
src/features/linked-results/result-message.ts | 1 +
src/features/project-import/DataHub.tsx | 125 +++-
.../project-import/DatahubHistoryOverview.tsx | 17 +-
.../project-import/GpoFolderImport.tsx | 202 +++++-
.../MicrosoftBaselineLibrary.tsx | 13 +-
.../project-import/PolicyAnalysisActions.tsx | 17 +-
.../project-import/PolicyAnalysisPanel.tsx | 104 +++-
.../canonical-model-to-dataset.ts | 34 +-
.../project-import/datahub-open-readiness.ts | 26 +
.../datahub-processing-readiness.ts | 22 +-
.../load-canonical-project-workspace.ts | 65 +-
.../policy-observations-to-dataset.ts | 101 ++-
.../results-browser/ResultsBrowser.tsx | 29 +-
.../review-workspace/database-review.ts | 135 ++++
.../search-filter/WorkTimeslotControl.tsx | 19 +-
src/features/search-filter/dynamic-facets.ts | 35 +-
src/gpo/gpo-folder-transport.ts | 111 +++-
src/gpo/snapshot-builder.ts | 13 +-
src/importers/status-normalization.ts | 5 +-
src/persistence/assessor-repository.ts | 4 +-
src/persistence/local-assessor-repository.ts | 83 ++-
src/profiles/generic/generic-definition.ts | 3 +
src/profiles/group-policy/categories.ts | 57 ++
.../group-policy/conflict-presentation.ts | 117 ++++
src/profiles/group-policy/guidance.ts | 63 ++
src/profiles/group-policy/presentation.ts | 74 +++
.../group-policy/source-presentation.ts | 32 +
src/profiles/group-policy/web-search.ts | 115 ++++
src/profiles/group-policy/xml-presentation.ts | 68 ++
src/profiles/profile-factory.ts | 10 +
src/profiles/public-search/catalog.json | 364 +++++++++++
src/profiles/public-search/search.ts | 130 ++++
src/styles/components.css | 51 +-
src/styles/datahub-redesign.css | 1 +
src/styles/datahub.css | 161 ++++-
src/styles/layout.css | 9 +-
src/styles/legacy-views.css | 9 +
src/styles/policy-analysis.css | 16 +-
src/styles/ui-tokens.css | 8 +-
tests/api/assessor-api-client.test.ts | 27 +-
tests/app/app-version.test.ts | 25 +-
tests/app/work-scope.test.ts | 12 +-
tests/components/panel-loading-state.test.tsx | 21 +
tests/components/path-text.test.tsx | 63 ++
tests/design-language-check.mjs | 9 +-
tests/domain/gpo-ingestion.test.ts | 14 +-
tests/domain/gpo-unified-result.test.ts | 305 +++++----
tests/domain/policy-analysis-actions.test.ts | 12 +
tests/domain/policy-analysis-overview.test.ts | 2 +-
.../result-db-supplemental-disclosure.test.ts | 72 +++
tests/evaluation/policy-comparator.test.ts | 12 +
tests/exports/unified-result-jsonl.test.ts | 35 ++
.../canonical-model-to-dataset.test.ts | 6 +
.../dashboard-progressive-disclosure.test.tsx | 8 +-
tests/features/database-review.test.ts | 63 ++
.../features/datahub-centered-layout.test.ts | 27 +
tests/features/datahub-client-open.test.ts | 5 +-
tests/features/datahub-gpo-open.test.ts | 32 +
.../datahub-gpo-report-visibility.test.ts | 21 +-
tests/features/datahub-open-readiness.test.ts | 19 +
.../datahub-processing-readiness.test.ts | 27 +
.../datahub-tenant-detail-reference.test.ts | 26 +-
.../db-structure-interaction.test.tsx | 54 ++
tests/features/db-structure-layout.test.ts | 53 ++
tests/features/finding-reader.test.ts | 30 +
tests/features/gpo-category-badges.test.tsx | 99 +++
tests/features/gpo-conflict-results.test.tsx | 109 ++++
tests/features/gpo-duplicate-results.test.tsx | 104 ++++
.../features/gpo-folder-file-capture.test.ts | 103 ++++
.../features/gpo-source-presentation.test.tsx | 46 ++
tests/features/gpo-work-projection.test.ts | 198 ++++--
tests/features/gpo-xml-presentation.test.tsx | 73 +++
.../group-policy-presentation.test.ts | 16 +
.../import-progress-indicator.test.ts | 15 +-
.../load-canonical-project-workspace.test.ts | 56 +-
tests/features/pass-outcome-color.test.ts | 36 ++
tests/features/policy-analysis-panel.test.tsx | 29 +-
tests/features/policy-guidance.test.tsx | 182 ++++++
tests/features/policy-search-context.test.ts | 69 +++
tests/features/public-search.test.tsx | 114 ++++
.../results-browser-timeslot-scope.test.ts | 29 +-
tests/features/tile-card.test.ts | 59 +-
tests/features/tile-segment-grammar.test.ts | 2 +-
tests/features/work-timeslot-control.test.ts | 2 +-
tests/features/work-timeslot-state.test.ts | 6 +-
tests/local-only-check.mjs | 9 +-
tests/persistence/assessor-repository.test.ts | 10 +-
tests/persistence/unified-result.test.ts | 31 +-
.../postgres/canonical-local-database.test.ts | 20 +
.../gpo-backup-management.integration.test.ts | 2 +-
.../policy-analysis.integration.test.ts | 13 +
.../postgres/policy-evaluation-schema.test.ts | 12 +
tests/server/assessor-http-server.test.ts | 17 +-
.../gpo-automatic-analysis-service.test.ts | 126 ++++
tests/server/gpo-backup-ingestion.test.ts | 46 ++
tests/server/gpo-backup-job-processor.test.ts | 32 +-
.../gpo-backup-management-service.test.ts | 46 +-
tests/server/gpo-environment-context.test.ts | 26 +
tests/server/gpo-folder-transport.test.ts | 17 +
tests/server/gpo-metadata-parser.test.ts | 32 +
.../gpo-policy-evaluation-service.test.ts | 579 ++++--------------
...microsoft-security-baseline-parser.test.ts | 17 +
.../microsoft-security-baseline.test.ts | 14 +
vite.client.config.ts | 6 +-
180 files changed, 6734 insertions(+), 1325 deletions(-)
create mode 100644 docs/architecture/policy-analyzer-comparison-contract.md
create mode 100644 docs/architecture/public-ai-search.md
create mode 100644 server/gpo/gpo-automatic-analysis-service.ts
create mode 100644 server/gpo/gpo-environment-context.ts
create mode 100644 server/gpo/policy-target-resolver.ts
create mode 100644 server/postgres/migrations/019_native_policy_targets.sql
create mode 100644 server/postgres/migrations/020_baseline_driven_policy_evaluation.sql
create mode 100644 src/components/OperationProgress/OperationProgress.tsx
create mode 100644 src/components/PanelLoadingState/PanelLoadingState.tsx
create mode 100644 src/components/PathText/PathText.tsx
create mode 100644 src/domain/assessor-release.ts
create mode 100644 src/domain/policy-comparison-disposition.ts
create mode 100644 src/domain/result-db-supplemental-disclosure.ts
create mode 100644 src/evaluation/policy-work-results.ts
create mode 100644 src/features/about/AboutDialog.tsx
create mode 100644 src/features/project-import/datahub-open-readiness.ts
create mode 100644 src/features/review-workspace/database-review.ts
create mode 100644 src/profiles/group-policy/categories.ts
create mode 100644 src/profiles/group-policy/conflict-presentation.ts
create mode 100644 src/profiles/group-policy/guidance.ts
create mode 100644 src/profiles/group-policy/presentation.ts
create mode 100644 src/profiles/group-policy/source-presentation.ts
create mode 100644 src/profiles/group-policy/web-search.ts
create mode 100644 src/profiles/group-policy/xml-presentation.ts
create mode 100644 src/profiles/public-search/catalog.json
create mode 100644 src/profiles/public-search/search.ts
create mode 100644 tests/components/panel-loading-state.test.tsx
create mode 100644 tests/components/path-text.test.tsx
create mode 100644 tests/domain/result-db-supplemental-disclosure.test.ts
create mode 100644 tests/features/database-review.test.ts
create mode 100644 tests/features/datahub-gpo-open.test.ts
create mode 100644 tests/features/datahub-open-readiness.test.ts
create mode 100644 tests/features/db-structure-interaction.test.tsx
create mode 100644 tests/features/db-structure-layout.test.ts
create mode 100644 tests/features/gpo-category-badges.test.tsx
create mode 100644 tests/features/gpo-conflict-results.test.tsx
create mode 100644 tests/features/gpo-duplicate-results.test.tsx
create mode 100644 tests/features/gpo-folder-file-capture.test.ts
create mode 100644 tests/features/gpo-source-presentation.test.tsx
create mode 100644 tests/features/gpo-xml-presentation.test.tsx
create mode 100644 tests/features/group-policy-presentation.test.ts
create mode 100644 tests/features/pass-outcome-color.test.ts
create mode 100644 tests/features/policy-guidance.test.tsx
create mode 100644 tests/features/policy-search-context.test.ts
create mode 100644 tests/features/public-search.test.tsx
create mode 100644 tests/postgres/canonical-local-database.test.ts
create mode 100644 tests/server/gpo-automatic-analysis-service.test.ts
create mode 100644 tests/server/gpo-environment-context.test.ts
create mode 100644 tests/server/gpo-metadata-parser.test.ts
diff --git a/AGENTS.md b/AGENTS.md
index d2136ed..f1a735e 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -18,9 +18,17 @@
- Treat Tauri as the current local shell and a possible optional future shell. Do not make new domain logic depend on Tauri when a platform-neutral boundary is possible.
- The target deployment is an internal browser application with a backend and PostgreSQL. The browser must not access the database directly.
+## Canonical local PostgreSQL
+
+- The single canonical local ASSESSOR datastore for this workspace is the existing Docker Compose project `assessor-2_0`, container `assessor-2_0-postgres-1`, database `assessor`, and volume `assessor-2_0_assessor-postgres-data` on `127.0.0.1:5432`.
+- Every local App/Backend start must reuse that datastore. Never create an alternative ASSESSOR database, Compose project, PostgreSQL volume, or fallback port for this workspace.
+- If the canonical datastore is unavailable or port `5432` is occupied by a different container, stop and report the conflict instead of spawning or selecting another database.
+- `docker-compose.postgres.yml` must keep the canonical Compose project name and external volume binding. Never delete, replace, recreate, or initialize the canonical volume as an empty datastore.
+- Before an approved persistence migration or destructive database operation, create and verify a backup. Unrelated Docker applications, containers, and volumes remain out of scope.
+
## UI typography
-- Use the locally bundled Inter variable font as the single application typeface. Do not introduce view-specific display, condensed, serif, or monospace families; hierarchy comes from size and weight.
+- Use the locally bundled Inter variable font as the application typeface. Do not introduce view-specific display, condensed or serif families; hierarchy comes from size and weight. Explicit user exception: paths use the shared technical-path textbox and local system monospace stack; other content remains Inter. Do not download additional fonts.
- Use only the visual weights Regular 400, Semibold 600, and Bold 700. Bold is reserved for branding and exceptional emphasis.
- Use the semantic typography roles: H1 56px/600, H2 32px/600, H3 18px/600, detail titles 20px/600, H4 16px/600, continuous prose 16px/400, structured table/Grid/Raw Data content 14px/400, labels and table headers 12px/600, metadata 12px, badges 11px, and buttons/controls 13px/600.
- Preserve normal title case for H1-H4, field labels, and buttons. Uppercase is limited to compact table headers, badges/categories, and the ASSESSOR wordmark.
diff --git a/docker-compose.postgres.yml b/docker-compose.postgres.yml
index b6b8e46..ef1a351 100644
--- a/docker-compose.postgres.yml
+++ b/docker-compose.postgres.yml
@@ -1,3 +1,5 @@
+name: assessor-2_0
+
services:
postgres:
image: postgres:16-alpine
@@ -18,3 +20,5 @@ services:
volumes:
assessor-postgres-data:
+ name: assessor-2_0_assessor-postgres-data
+ external: true
diff --git a/docs/IMPLEMENTATION_PLAN.md b/docs/IMPLEMENTATION_PLAN.md
index 3b058c9..c22df2a 100644
--- a/docs/IMPLEMENTATION_PLAN.md
+++ b/docs/IMPLEMENTATION_PLAN.md
@@ -1,6 +1,76 @@
# ASSESSOR – Umsetzungsplan
Status: lebendes Projektdokument
+
+GPO-Kachelbadges 2026-09-06 (Phase 7): TileCard verwendet jetzt dieselbe GPO-Kategorieableitung wie der FindingReader und ergaenzt Scope. Gilt auch fuer gemischte Workspaces; doppelte Kategorien/Scopes werden vermieden, andere Scanner bleiben unveraendert. Bestehende Badge-Matrix und unbegrenzte normale Kacheldarstellung werden weiterverwendet. Vier neue synthetische Regressionen; 962 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Keine Daten-/Bewertungsaenderung, kein Reimport, keine Realdateninspektion oder visuelle Live-Abnahme; Phasenstatus unveraendert.
+
+GPO-Duplicate-Results 2026-09-06 (Phase 7): Duplicates nutzen analog zu Conflicts den bestehenden Results-Button und dieselbe skalierbare Tabellenansicht. Eine Tabelle zeigt den gemeinsamen Originalwert, Typ und Quellenanzahl; eine zweite jede Quelle mit Source path, Backup und Record. Einstellung, Scope, Registry-Pfad und Value name stehen im Kontext. Keine Konflikt-/Gewinnermarkierung bei gleichen Werten. Der Reader zeigt eine kurze Duplicate-Zusammenfassung statt wiederholter Werte/Sources. Gemeinsame begrenzte, inerte Leseprojektion mit eindeutig getrennten Envelopes und Whitespace-Erhaltung; bei unvollstaendiger/mehrdeutiger Evidenz bleibt die bisherige Darstellung erhalten. Bewertung, Persistenz und Originaldaten unveraendert; kein Reimport erforderlich, bestehende Workspaces neu oeffnen. Sieben neue synthetische Regressionen inklusive 2.300 Quellen, Buttonaktivierung, Escaping, Fallback und unveraenderten Konflikten. 958 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Keine Realdateninspektion oder visuelle Live-Abnahme; Phasenstatus unveraendert.
+
+Tooluebergreifende AI search und GPO-Badges 2026-09-06 (Phase 7): FindingReader bietet die geschuetzte Google-AI-Suche fuer alle Scan-Tools und gemischte Workspaces an. Quellenbelegter lokaler Public-Identifier-Snapshot (67 Registryziele, 45 Rechte, 19 ASR-, 161 Maester- und 51 PingCastle-Kennungen) plus native System-Access-Einstellungen und feste Fachbegriffe liefern konkrete Identitaet, Konfigurationsort/Referenz, sicheren Benchmarkkontext und begrenzte numerische/boolesche Sollziele. Keine freie Weitergabe von Berichtstexten, Kundenwerten, Namen, Identitaeten oder Quellpfaden. Fehlende Katalogtreffer bleiben ausdruecklich Topic-Suche; keine Vollstaendigkeits-, Wirksamkeits- oder Datenschutzpauschalzusage. Vorhandene GPO-Sektionen erzeugen zusaetzliche System-Access-/Privilege-Rights-/Registry-Values- und Detailbadges; Registry/Software/System sind strukturelle Fallbacks hinter konkreten Produktfamilien. Keine Bewertungs-/Persistenzaenderung oder Reimporte. Sicherheitsmodell und Public-AI-Search-Vertrag mit Quellenpflege/Grenzen ergaenzt; historische Entscheidungen bleiben erhalten. 951 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Nur synthetische Inhaltspruefungen, keine Kundendateninspektion oder Google-Abfrage mit Findingdaten. Phasenstatus unveraendert.
+
+GPO-Kachelumbruch 2026-09-06 (Phase 7): Lange Registry- und Policy-Pfade in GPO-Work-Kacheln umbrechen innerhalb der verfuegbaren Titelspalte und koennen dadurch weder die Bookmark-Aktion noch benachbarte Kacheln ueberdecken. Die Regel ist ueber die bestehende Toolidentitaet gezielt auf `group-policy` begrenzt; normale Findingtitel behalten ihren wortbasierten Umbruch. 42 fokussierte synthetische Tests, Designpruefung und Client-Produktionsbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Pfaddarstellung 2026-09-06 (Phase 7): Gemeinsame inerte PathText-Darstellung fuer Finding-/Reporttexte, GPO-Werte/Sources/Remediation und Results-Tabellen samt Kontext. Pfade erhalten einen dezenten Rahmen mit themegebundener Inset-Flaeche, vollstaendigem Umbruch und lokaler System-Monospace-Schrift. Ausdrueckliche Nutzerkorrektur zur bisherigen reinen Inter-Vorgabe: nur Pfade nutzen --font-path, Labels und sonstige Inhalte bleiben Inter; AGENTS.md entsprechend praezisiert. Keine Links, Dateizugriffe, Fontdownloads oder Aenderungen an Originalwerten/Vergleichen. Zwoelf synthetische Regressionen pruefen Pfadtypen, Labels, Escaping, Suchmarkierung, lange Pfade und Stilkontrakt. 923 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung sowie Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Keine Realdateninspektion oder visuelle Live-Abnahme; Phasenstatus unveraendert.
+
+GPO-Conflict-Results 2026-09-06 (Phase 7): Kundenkonflikte mit mehreren belegten Wertvarianten nutzen den vorhandenen Results-Button samt verschiebbarem/skalierbarem Ergebnisfenster und gemeinsamer Tabelle. Gleiche typisierte Werte werden zu Varianten gruppiert, unterschiedliche Value-/Type-Spalten mit dem gemeinsamen Warning-Akzent markiert; keine Variante wird als Gewinner oder Baseline-Sollwert behauptet. Gemeinsame Einstellung/Scope/Pfad stehen einmal im Results-Kontext, eine zweite Tabelle bindet jede Source an Variante, Originalpfad, Backup und Record. Der Reader zeigt eine kurze Konfliktzusammenfassung statt wiederholter Kundenwerte/Sources; ohne gueltige strukturierte Details bleibt die bisherige Evidenzdarstellung erhalten. Inerte, begrenzte JSON-Leseprojektion mit Whitespace-Erhaltung, keine Migration/Neubewertung oder Originaldatenmutation. Acht synthetische Regressionen inklusive Typkonflikten, HTML-Inertheit, aktivem Results-Button, Fallback und 2.300 Quellen; 911 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Keine Realdateninspektion oder visuelle Live-Abnahme; Phasenstatus unveraendert.
+
+GPO-Misconfiguration-Fokus 2026-09-06 (Phase 7/13B, ausdrueckliche Nutzerkorrektur): Deviation enthaelt fuer GPOs nur gesetzte Kundenwerte mit expliziter vorhandener Baseline und deterministischer Abweichung. Fehlende Einstellungen werden als Not configured/informational separat angezeigt, nicht als Fail/Deviation; Conflicts und Duplicates bleiben eigene Filter ohne Deviation-Zaehlung. Der neue reine Lesekontrakt gilt fuer Work, Dashboardfilter, Result-DB-Vergleichsprojektion und bereits materialisierte Factory-Ergebnisse (Rueckbindung an deren gespeicherten Vergleich, ohne fehlende Evidenz Fail zu behaupten). Gemischte Scanner/GPO-Profile behalten die separaten Filter; Scanner-Semantik unveraendert. GPO Analysis trennt Misconfigured/Not configured und zaehlt betroffene Settings sowie GPO-Backupinstanzen dedupliziert; alte Historienzaehler sind ausdruecklich als gespeicherte Mismatches einschliesslich fehlender Werte bezeichnet. Work-Projektion 1.2.0, Result-DB-Praesentation 1.1.0; keine Migration, Reimporte oder Mutation gespeicherter Evaluationen/Originale. Ersetzt die bisherige fehlende-Werte-als-Fail-Entscheidung; Vergleichs-/Resultvertrag angepasst. 903 Tests bestanden, 8 optionale PostgreSQL-Integrationstests uebersprungen, Local-only-/Designpruefung sowie Client-/Serverbuild erfolgreich. Laufendes Entwicklungsbackend per inhaltsfreiem Health-/Buildhash-Abgleich aktuell; keine Kundendateninspektion oder Live-Inhaltsabnahme. Phasenstatus unveraendert.
+
+AI-Suchkontext 2026-09-06 (Phase 7): Auf Nutzerwunsch ergaenzt der Suchlink Scope, exakt freigegebene Baselinebezeichnungen und feste Vergleichsszenarien. Bekannte Audit-Abhilfe fuer System Integrity/Logoff wird aus eindeutigen booleschen Sollflags, Expected/Must include und passendem Titel/Scope aufgebaut; keine freie Textweitergabe. Description-Platzhalter und unverifizierte importierte Beschreibungen/Abhilfetexte bleiben ausgeschlossen. Sicherheitsmodell dokumentiert die eng begrenzte Freigabe und verbleibende Google-IP-/Kontodatenverarbeitung ohne DSGVO-Pauschalzusage. Sechs neue synthetische Datenschutz-/Kontexttests; 898 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Hinweis). Keine Kundendateninspektion, Suchausfuehrung mit Findingdaten oder Datenmutation. Phasenstatus unveraendert.
+
+AppLocker-Wertdarstellung 2026-09-06 (Phase 7): AppLocker-XML erscheint als lesbare Regelfelder statt Roh-XML/Codeblock in Kundenwert, Baselinewert, abgeleiteter Remediation und Sources. Bedingungen, Ausnahmen, Versionsgrenzen, IDs und unbekannte Erweiterungen bleiben erhalten. Begrenzter SAX-Formatter in der Praesentationsschicht; fehlerhafte/unsupported Werte bleiben escapeter Originaltext ohne aktive Links oder HTML. Vergleich, Persistenz und Originaldaten unveraendert. Sieben neue synthetische Regressionen, bestehende Reader-Pruefung angepasst; 892 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Bestehender Bundle-Groessenhinweis; keine Realdateninspektion oder visuelle Live-Abnahme. Phasenstatus unveraendert.
+
+Remediation-Hervorhebung 2026-09-06 (Phase 7): Remediation-Abschnitte im FindingReader sind auf Nutzerwunsch mit derselben dezenten Gruenflaeche und Akzentlinie wie Expected baseline value hinterlegt. Gemeinsamer Success-Token fuer beide Themes; Beschreibung, Sources, Inhalte und Bewertung bleiben unveraendert. Synthetische Renderingregression; 885 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Keine Datenmutation; Phasenstatus unveraendert.
+
+Praezise Google-AI-Suche 2026-09-06 (Phase 7): Der bisherige Web-search-Button heisst AI search und verwendet einen Google-AI-Mode-Deep-Link. Die oeffentliche Begriffsliste erkennt jetzt zwoelf konkrete Firewall-Einstellungen und deren Domain-/Private-/Public-Profil sowie feste Microsoft-Produktversionen; doppelte Oberbegriffe wie Windows Windows Firewall entfallen. Der Prompt fragt nach Sicherheitszweck, Konfigurationsort und versionsabhaengiger Microsoft-Baselineempfehlung mit offiziellen Quellen. Keine rohe Titel-/Pfad-/Wertweitergabe; unbekannte Einstellungsnamen bleiben bei einem allgemeinen Thema. Referrer-/Opener-Schutz und expliziter Klick bleiben unveraendert, Sicherheitsmodell fortgeschrieben. Google-Dokumentation bestaetigt den allgemein verfuegbaren AI Mode, waehrend Zusatzfunktionen/Limits/Kontoverfuegbarkeit anbieterabhaengig sind; keine Garantie fuer externe Antworten. 884 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Nur synthetische Datenschutz-/URL-/UI-Tests; ein oeffentlicher Deep-Link-Abruf war ueber das Recherchewerkzeug nicht verfuegbar, keine Live-Abnahme im Google-Konto. Keine Kundendaten oder Bewertungsaenderungen; Phasenstatus unveraendert.
+
+GPO-Sources-Darstellung 2026-09-06 (Phase 7): Sources wird aus den vorhandenen strukturierten Beobachtungen als getrennte, nummerierte Quellbloecke mit Source path, Scope, Registry path, Value name, Value, lesbarem Registrytyp und Operation projiziert. Backup-/Recordreferenzen und optionale Targets/Secure-Angaben bleiben erhalten; keine kompakte JSON-Kette fuer Registrywerte. Native Policywerte werden lesbar formatiert. Der Reader rendert Sources als escapeten Text mit Zeilenumbruechen und Pfadumbruch, nicht als HTML oder externe Links. Originaldaten und Vergleich bleiben unveraendert. Vier synthetische Regressionen einschliesslich Nullwert, mehreren/2.300 Quellen, Auditflags und inerten Pfaden; 880 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Keine Realdateninspektion; Phasenstatus unveraendert.
+
+GPO-Beschreibung, Abhilfe und sichere Websuche 2026-09-06 (Phase 7/13B): Work laedt zu den ausgewaehlten Evaluationen einmal je referenzierter Baseline die vorhandenen Analysen ueber die bestehende API. Originale ADML-Erklaertexte werden ausschliesslich ueber die exakte Analysis-/Baseline-/Catalog-/Policy-/Sprachdateizuordnung aufgeloest (Englisch bevorzugt); fehlende oder widerspruechliche Texte werden nicht erfunden. Description source bleibt unter Additional Information. Remediation wird als Einstellungsziel und vorhandener Baseline-Sollwert mit Vergleichsoperator abgeleitet, nicht als behauptete Microsoft-Schrittanleitung; keine Abhilfe gegen leere oder widerspruechliche Vorgaben. Reine Leseprojektion fuer vorhandene Evaluationen, keine Reimporte, Neuauswertungen, Persistenz- oder Schemaaenderungen. Dokumentationsfehler blockieren Work nicht. Der Button Web search oeffnet erst bei Klick eine Google-Suche auf Microsoft Learn; Queries bestehen ausschliesslich aus fest freigegebenen oeffentlichen Begriffen (bekannte Einstellungen oder allgemeines Fachthema), niemals aus importierten Titeln, Kundendaten, Pfaden oder Werten. Referrer/Opener sind gesperrt, Beschreibung und Abhilfe bleiben inerte Textdarstellung. Die explizit freigegebene externe Navigation samt Grenzen ist im GPO-Bedrohungsmodell dokumentiert; Sentinal diente nur als UI-Referenz, dessen direkte Titelweitergabe wurde nicht uebernommen. 876 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Ausschliesslich synthetische Tests, keine Realdateninspektion und kein Test-Suchaufruf. Phase 7 bleibt abgeschlossen, Phase 13B in Arbeit.
+
+Pass-Farbe 2026-09-06 (Phase 7, ausdrueckliche Nutzerkorrektur): Der gemeinsame Outcome-Token fuer Pass/Passed ist in beiden Themes gruen statt grau. Dies ersetzt die bisherige bewusste Gruen-Ausnahme fuer bestandene Ergebnisse; Severityfarben und fachliche Statusnormalisierung bleiben unveraendert. Liste, FindingReader und andere gemeinsame Outcome-Anzeigen nutzen denselben Token. Synthetische Regression prueft mindestens 4,5:1 Textkontrast auf Panel-, erhoehten, aktiven und ausgewaehlten Listenflaechen beider Themes. 866 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Keine Datenmutation, keine Live-Inhaltsinspektion; Phasenstatus unveraendert.
+
+GPO-Scope-Badge 2026-09-06 (Phase 7): Der vorhandene Scope erscheint zusaetzlich als kompaktes Badge im FindingReader; das Scope-Feld in der Reportansicht bleibt unveraendert erhalten. Fehlende/leere Werte erzeugen kein Badge. Drei synthetische Regressionen fuer computer, user und fehlenden Scope; 864 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich. Keine Daten- oder Bewertungsaenderung; Phasenstatus unveraendert.
+
+GPO-Kategorie-Badges 2026-09-06 (Phase 7): Der FindingReader zeigt neben GPOs kurze abgeleitete Produkt-/Bereichsbadges: Windows, Office, Edge sowie Audit, Defender, Firewall, BitLocker, LAPS oder allgemein Security. Die reine Praesentationszuordnung verwendet Baselinebezeichnung, expliziten Registry-Pfad und Policytyp/-sektion; unbekannte Einstellungen erhalten keine erratene Spezialkategorie. Baseline-only-Auditvergleiche bleiben auch ohne Kundenwert als Audit erkennbar. Produktbadges beschreiben den Benchmark, nicht die nachgewiesene Zielanwendbarkeit; die Bereichstaxonomie ist eine ASSESSOR-Anzeige, keine neue Microsoft-Bewertung. Keine Aenderung an Outcomes, Persistenz, API oder Quelldaten. 861 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich (bestehender Bundle-Groessenhinweis). Nur synthetische Tests; keine Realdateninspektion oder visuelle Live-Abnahme. Phase 7 bleibt abgeschlossen.
+
+GPO-Finding-Ueberschrift 2026-09-06 (Phase 7, Produktversion 2.5.4): Der normalisierte `Value Name` einer GPO-Registry-Einstellung bildet jetzt die Ueberschrift des Finding-Abschnitts. Derselbe Wert wird im Block `Configured customer value` nicht wiederholt; konfigurierte und erwartete Werte bleiben direkt vergleichbar. Persistierte Quellwerte und Vergleichslogik bleiben unveraendert. 843 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Ausschliesslich synthetische Tests, keine Daten-, API-, Persistenz- oder Schemaaenderung. Phase 7 bleibt abgeschlossen.
+
+GPO-Analyse-UX-Korrektur 2026-09-06 (Phase 7/13B, Produktversion 2.5.3): Der nicht abgestimmte Sammelstatus `Limited analysis` ist wieder entfernt. Ein technisch partiell abgeschlossener GPO-Import wird im Timeslot als `Imported` und im Importdetail als `Imported with review items` ausgewiesen; ohne konkrete Nutzeraktion bleibt der Client bereit und erhaelt kein automatisches Manage. Die Standardansicht der GPO Analysis zeigt jetzt ausschliesslich Importumfang, Baselineergebnisse und konkret benannte Importprobleme; Abweichungen werden als einzelne Einstellungsvergleiche erklaert. Workflow, Historie, Review-Codes und Processing-Aktionen bleiben fuer Diagnosezwecke unter `Technical details` beziehungsweise `Processing controls` aufklappbar. Im Work-Finding stehen der konfigurierte Kundenwert und der erwartete Baselinewert direkt untereinander, werden fuer lesbare Anzeige formatiert und bei Abweichungen rot/gruen markiert; persistierte Quellwerte bleiben unveraendert. 843 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Ausschliesslich synthetische Tests, keine Daten-, API-, Persistenz- oder Schemaaenderung. Phase 7 bleibt abgeschlossen, Phase 13B in Arbeit. Diese Nutzerkorrektur ersetzt die unmittelbar vorherige Statusentscheidung fuer `Limited analysis`.
+
+GPO-only-Timeslot-Scope 2026-09-06 (Phase 7/13B): Alle Clientansichten erkennen einen ausgewaehlten Timeslot nun zentral sowohl ueber Scanner-Run-IDs als auch ueber Assessment-IDs. Damit funktionieren reine GPO-Timeslots in Client Info, Work, Result DB und Pathfinder, ohne faelschlich `No timeslot selected` anzuzeigen oder einen Scannerlauf aus einem anderen Stand einzumischen; Datahub und DB Structure bleiben wie bisher unabhaengig vom geladenen Scannertyp. Result-DB-Laden und -Export verwenden denselben projekt- und assessmentgebundenen Scope. 25 fokussierte synthetische Tests, Designpruefung und Client-Produktionsbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen und Phase 13B in Arbeit.
+
+Status und Aenderungsprotokoll 2026-09-06 (Phase 7, Produktversion 2.5.2): `Partial import` beziehungsweise `Partially processed` heisst jetzt `Limited analysis`. Abgeschlossene eingeschraenkte Analysen und laufende GPO-Jobs sind eigene gelbe Informationszustaende; sie loesen weder automatisches Manage noch eine automatische Expansion als Handlungsaufforderung aus. Fehler/Recovery und notwendige Scanner-Reimporte behalten Vorrang und automatisches Manage; die manuelle Verwaltung ausgewaehlter Clients bleibt verfuegbar. Diese Nutzerkorrektur ersetzt die bisherige Gleichsetzung aller nicht erfolgreichen GPO-Zustaende mit Handlungsbedarf. Analysegrenzen bleiben sichtbar und werden nicht als vollstaendige Auswertung bezeichnet. 839 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Ausschliesslich synthetische Tests; keine fachliche Pipeline-, Daten- oder Schemaaenderung. Phase 7 bleibt abgeschlossen, Phase 13B in Arbeit.
+
+UI-Sprache 2026-09-06 (Phase 7, verbindliche Produktvorgabe): Saemtliche nutzerseitig sichtbaren Texte in ASSESSOR werden auf Englisch formuliert. Das gilt insbesondere fuer Navigation, Titel, Labels, Buttons, Status-, Lade-, Leer-, Fehler-, Bestaetigungs- und Dialogtexte sowie neu hinzukommende Funktionen. Deutsche Texte duerfen nur in interner Dokumentation, Kommentaren oder ausdruecklich angeforderten Exportinhalten vorkommen. Der verbliebene Ladehinweis der Data-Hub-Historie lautet nun `Loading clients …`. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Panel-Ladezustand 2026-09-06 (Phase 7): Inhaltsbereiche mit initialem, asynchronem Laden verwenden nun einen gemeinsamen, markenfreien Ladezustand: Der jeweils konkrete Ladetext steht mit der aus den Processing-Pop-ups bekannten quadratischen Ladeanimation unmittelbar daneben mittig im verfuegbaren Panelbereich. Client Info, DB Structure, Result DB, Data-Hub-Historie, Timeslot-Liste und Policy Analysis sind angebunden; kleinere eingebettete Bereiche verwenden dieselbe Darstellung kompakter. Fehler-, Leer- und laufende Operationsdialoge bleiben fachlich getrennt. 835 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-Produktionsbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+GPO-Importkorrektur 2026-09-06 (Phase 13B): Byte-identische Policydateien an unterschiedlichen Pfaden erhalten nun unterschiedliche, weiterhin deterministische Observation-IDs, weil der exakte Quellartefaktbezug Bestandteil der ID ist. Damit wird ein gueltiges Kundenbackup nicht mehr als `duplicate-observation` atomar abgelehnt. Der automatische Pfad verlangt bei einem reinen GPO-Backup keinen zusaetzlichen Betriebssystemkontext mehr, sondern wertet alle importierten, als `eligible` klassifizierten Microsoft-Baselines als getrennte Benchmarks aus; erkannte DC-Kontexte bleiben als Evidenz erhalten. Ein gemeinsam hochgeladener `selected-gpos`-Satz bleibt auch bei fehlenden oder gemischten Domainmetadaten ein einzelner, bewusst partieller Snapshot statt in nicht auswertbare Einzelsnapshots zu zerfallen. Parser-/Analyzervertrag 2.2.2, Snapshotaggregation 1.1.0 und Produktversion 2.5.1 markieren die kompatible Fehlerkorrektur. Synthetische Regressionen fuer zwei identische Security-Template-Dateien an verschiedenen Pfaden, kontextfreien Auto-Vergleich, Baseline-Auswahl, gemischte Uploadmetadaten und den 2.300-GPO-Lastfall sind gruen. Inhaltsfreie technische Kontrolle am betroffenen Import: Status-API HTTP 200, kein fehlgeschlagener Job, 184 erkannte GPOs sowie 3.638 Work-Ergebnisse mit 162 Uebereinstimmungen und 3.358 Abweichungen; Quellinhalte wurden weder ausgegeben noch manuell inspiziert. Gesamtlauf: 835 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine SQL-Migration; Phase 13B bleibt in Arbeit.
+
+GPO-Statuspraezisierung 2026-09-06 (Phase 7/13B): Ein vollstaendig erfolgreich verarbeiteter GPO-Backup-Eintrag zeigt im Timeslot `Ready` statt des rein uploadbezogenen `Imported`. Queued, Processing, Partial import, Failed und Recovery pending bleiben unveraendert, damit technische Zwischen-, Teil- und Fehlerzustaende weiterhin sichtbar sind. Zehn fokussierte synthetische Tests und Client-Produktionsbuild erfolgreich; keine Daten-, API-, Persistenz- oder Schemaaenderung.
+
+Branding-Korrektur 2026-09-06 (Phase 7): Die ASSESSOR-Marke verwendet in Sidebar, leerem Arbeitsbereich, Favicon und About-Dialog ein gemeinsames PNG mit echter Transparenz; weisser Hintergrund, weisses A-Innenfeld und weisser Haken sind entfernt, nur die rote Marke bleibt. Der klickbare Brand-Trigger behaelt Position und zugaengliche About-Beschriftung, zeigt beim Hover jedoch keine Buttonflaeche. Der bestehende About-Dialog stellt die Marke mit 160 px dominant ueber den Produkt- und Processingdaten dar. Fuenf fokussierte Tests und Client-/Serverbuild erfolgreich; keine Daten-, API-, Persistenz- oder Schemaaenderung, Phase 7 bleibt abgeschlossen.
+
+Review-Persistenz und Vergleichsplanung 2026-09-06 (Phase 8/9/10): Die FindingReader-Felder Bookmark, Status, Prioritaet, Owner/Team, Due Date, Prerequisites, Required Access/Roles, Next Step, Evidence/Acceptance Criteria, Comment und alle fuenf Marker sind ueber die bestehende Same-Origin-Review-API an das kanonische Finding-Vorkommen gebunden und werden in der ASSESSOR-Datenbank gespeichert. Aggregate und Werkzeugblatt teilen dadurch denselben Reviewstand; vorhandene Browserwerte bleiben als Rueckfallkopie erhalten und werden bei noch fehlendem Datenbankreview uebernommen. Additive JSONB-Vertragserweiterung, keine SQL-Migration und keine Realdateninspektion. Das unten in Phase 8 ausformulierte Quellen-Fortschreibungsmodell ist als spaeteres Arbeitspaket beschlossen, aber noch nicht implementiert.
+
+GPO-Loeschkorrektur 2026-09-06 (Phase 7/13B): Jeder beendete GPO-Eintrag im Timeslot besitzt neben Evaluate beziehungsweise Retry eine eigene Delete-Aktion mit Warnungsdialog. Die bestaetigte projekt-/artefaktgebundene Mutation entfernt das ausgewaehlte GPO-Original, Processing-/Identity-Historie und alle davon abhaengigen Snapshot-, Evaluation- und Finding-Derivate; Timeslot, Environment Profile, Scannerimporte und andere GPO-Eintraege bleiben erhalten. Queue-/Running-Zustaende sind gegen paralleles Loeschen gesperrt. 829 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Ausschliesslich synthetische Loeschtests; der GPO-Pfad benoetigt keine neue Migration und hat keine kanonischen Fachdaten mutiert. Beim anschliessenden Neustart wurde die bereits im Workspace anstehende Migration 020 nach Korrektur einer kollidierenden automatisch vergebenen Constraint-Bezeichnung auf dem kanonischen 2.0-Bestand angewandt; App und PostgreSQL-Backend melden HTTP 200. Phase 7 bleibt abgeschlossen und Phase 13B in Arbeit.
+
+UI-Textstandard 2026-09-06 (Phase 7, verbindlicher Nutzerwunsch): Funktionen mit kurzen, praegnanten Namen benennen, moeglichst ein Wort oder eine kurze Aktion. Name und Bedienelemente genuegen; keine ungefragten Erklaerabschnitte oder begleitenden Funktionsbeschreibungen. Gilt auch fuer GPO Analysis. Zusaetzliche Erlaeuterungen nur auf Nutzerwunsch; notwendige Fehler-/Sicherheitsmeldungen knapp und konkret halten. Der Timeslot-Importbereich heisst jetzt "Add Entry" ohne Beschreibung. Ersetzt die vorherige Entscheidung fuer den langen Hinzufuegen-/Erhaltungshinweis; keine Funktionsaenderung.
+
+UI-Korrektur 2026-09-06 (Phase 7): Timeslot-Gridzeilen behalten ihre Inhaltshoehe statt lange Details am unteren Rand abzuschneiden. Die Quellenliste ist auf maximal 40vh/384px begrenzt und separat scrollbar; Importaktionen liegen ausserhalb und sind bei jedem aufgeklappten Slot unabhaengig von der Checkbox verfuegbar. 809 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Client-/Serverbuild, Local-only und Designpruefung erfolgreich. Keine Datenmutation oder visuelle Browserabnahme; Phasenstatus unveraendert.
+
+UI-Praezisierung 2026-09-06 (Phase 7): Eintragsaktionen bleiben auch in schmalen Timeslot-Listen rechts neben dem zugehoerigen Scan/GPO-Eintrag. Importaktionen sind als "Add entry to this timeslot" mit Erhaltungshinweis gekennzeichnet; "Entire timeslot / Delete timeslot" steht separat darunter. Der bestehende Importpfad fuegt ohne replacesScanRunId einen neuen Scan hinzu; keine Persistenzaenderung. 808 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Client-/Serverbuild, Local-only und Designpruefung erfolgreich. Keine visuelle Browserabnahme; Phasenstatus unveraendert.
+
+Praezisierung 2026-09-06 (Phase 7, Nutzerkorrektur zur Open-Freigabe): Open bleibt auf Client-Kachel und einzelnem Time-Slot deaktiviert, bis gespeicherte Scanner-Findings oder Policy-Observations fuer den Assessment-Scope nachgewiesen sind. Upload-/Jobstatus allein reicht nicht. Die vorhandene Facetten-API liefert die Ergebniszaehler; ungeklaerte/fehlgeschlagene Abfragen sperren Open. Manage/View behalten ihre Diagnosefunktion. 807 Standardtests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only/Design erfolgreich. Keine neue API oder Datenmutation; Phase 7 bleibt abgeschlossen. Diese Freigaberegel ersetzt die vorherige Oeffnung leerer GPO-Workspaces.
+
+Korrektur 2026-09-06 (Phase 7 / 13B, ersetzt die vorherige GPO-Open-Sonderroute): Auf ausdruecklichen Nutzerwunsch oeffnet Open den Client in Client Info; ausschliesslich View fuehrt zur GPO-Analyse. GPO-only-Kacheln sind oeffenbar, der gewaehlte Assessment-Scope wird durch Workspace-Laden und Auffrischen weitergereicht und gegen automatische Scanner-Timeslot-Auswahl geschuetzt. Ohne Ergebnisse erscheint ein Client-Hinweis, alte Clientdaten werden beim Wechsel entfernt. Gemeinsame Hover-Regel fuer normale Quellenzeilenbuttons umfasst jetzt auch View in beiden Themes. Client-/Serverbuild, 14 fokussierte Tests sowie Local-only/Design erfolgreich. Gesamtlauf zuletzt 804 bestanden, 8 uebersprungen, ein anschliessend korrigierter synthetischer Test ohne Assessment-Zuordnung; betroffene Suite im fokussierten Nachlauf gruen. Fruehere Client-Open-Quelltextpruefung an neue Signatur und Whitespace angepasst. Keine Persistenz-/Backend-Aenderung oder visuelle Realdatenabnahme; Phasenstatus unveraendert.
+
+Nachpruefung 2026-09-06 (Phase 7 / GPO-Oberflaeche Phase 13B): Client-Verarbeitungsstatus umfasst jetzt Scanner und GPOs ueber alle Timeslots. Dead-letter und Recovery markieren den Client rot mit auswahlunabhaengigem Manage; ausstehende oder partielle GPO-Verarbeitung bleibt gelb, vollstaendig erfolgreiche gruen. GPO-Status wird alle fuenf Sekunden nachgeladen; Manage expandiert auch betroffene GPO-Timeslots. 13 fokussierte synthetische Tests inklusive unselektierter Fehlerkachel, Client-/Serverbuild sowie Local-only-/Designpruefung erfolgreich. Bekannter unabhaengiger Client-Open-Quelltexttest weiterhin rot. Keine Datenmutation oder visuelle Realdatenpruefung; Phasenstatus unveraendert.
+
+Nachpruefung 2026-09-06 (Phase 7): Retry in der GPO-Time-Slot-Zeile behaelt beim Hover die eigene Buttonflaeche und nutzt den gemeinsamen staerkeren Rand, damit es nicht mit dem Zeilenhover verschmilzt. Destruktiver Delete-Hover bleibt unveraendert. Client-/Serverbuild, Local-only und Designpruefung erfolgreich; der bekannte unabhaengige Client-Open-Quelltexttest bleibt rot. Rein lesende technische Jobpruefung: Ein GPO-Job steht nach 3/3 Versuchen wegen `gpo-metadata-size-limit` auf dead-letter; der Parser begrenzt einzelne Metadaten-XML-Dateien auf 2 MiB. Das Importlimit wurde nicht geaendert, kein Retry ausgeloest. Phase 7 bleibt abgeschlossen; keine visuelle Browserabnahme.
+
+Nachpruefung 2026-09-06 (Phase 7 / GPO-Oberflaeche Phase 13B): Schmale Time-Slot-Quellenlisten wechseln unter 620 px Containerbreite auf mehrzeilige Eintraege; Quellenzellen koennen schrumpfen und lange Dateinamen umbrechen. Open fuehrt bei einem einzelnen GPO-Time-Slot ohne anzeigbaren Scanner zur bestehenden projektweiten GPO-Analyse, auch waehrend der Verarbeitung. Mehrfachauswahl bleibt auf vergleichbare Scanner begrenzt. Vier fokussierte Tests und Client-/Serverbuild erfolgreich; Gesamtlauf: 798 bestanden, 8 uebersprungen, ein unabhaengiger Fehler im whitespace-abhaengigen Client-Open-Quelltexttest. Kein Nachweis fuer einen erfolgreich verarbeiteten realen GPO-Job und keine visuelle Browserabnahme; Phasenstatus unveraendert. Bestehende Datenbankkonfiguration bleibt unberuehrt.
Erstellt: 2026-07-17
Zuletzt aktualisiert: 2026-08-25
Aktuelle Entwicklungsstufe: lokale React-/Tauri-Anwendung
@@ -373,6 +443,8 @@ Abnahmekriterien:
Status: abgeschlossen
+Verifizierte Produktversionsanzeige vom 2026-09-06: Der Markenblock zeigt die zentrale npm-Produktversion, aktuell `ASSESSOR 2.5.1`, statt des davon unabhaengigen Processingvertrags. Der gesamte Markenblock oeffnet ein kompaktes About-Popup mit Produkt-, Build-, Backend-, Import- und GPO-Komponentenversionen sowie den dezenten Credits Michael Lukas und Binh Karl. Die Health-API meldet die Backend-Produktversion, sodass Frontend- und Backendstand erkennbar sind. Version 2.5.1 ist der erste kompatible Patch nach Einfuehrung von 2.5.0 und korrigiert den GPO-Import byte-identischer Dateien an verschiedenen Pfaden. 835 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Phase 7 bleibt abgeschlossen.
+
Verifizierte Result-DB-Filter-/Exportnachschaerfung vom 2026-09-03: Die Result DB startet und resettiert mit `Deviation = Yes`. Ein neuer `Export JSONL`-Button exportiert nicht nur die geladene Seite, sondern die vollstaendige aktuelle Filter- und Timeslot-Ergebnismenge ueber stabile Seitenabfragen. Zeile eins dokumentiert Format-/Schemaversion, Zeitpunkt, Scope, angewandte Filter und Ergebnisanzahl; danach folgt je Result genau ein vollstaendiges JSON-Objekt. Aendert sich die Ergebnismenge waehrend des Exports, wird der Download fail-closed abgebrochen. Drei fokussierte Export-/Scope-Tests und der Gesamtlauf mit 767 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
Verifizierte Client-Info-Balkenformatierung vom 2026-09-03: Die wiederverwendeten Kennzahlzeilen besitzen nun identische Label-, Balken- und Wertspalten sowie eine in jeder Zeile reservierte Statuszeile. Optionale `Restricted`-Hinweise verschieben dadurch keine Nachbarzeilen mehr; Zahlen, Einheiten und Balken bleiben ueber alle gleich breiten Karten ausgerichtet. Die kompakte Infrastructure-&-Resilience-Ausnahme behaelt ihre eigenstaendige Einspaltengeometrie. 13 fokussierte Dashboard-/Kacheltests, der Gesamtlauf mit 767 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine Fachlogik-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
@@ -409,6 +481,10 @@ Verifizierte Client-Info-Detailkorrektur vom 2026-09-03: Minimierte Informations
Verifizierte Client-Info-Standardansicht vom 2026-09-03: Beim Oeffnen ist ausschliesslich `Assessment Status` expandiert. Die acht uebrigen Mengen-/Faktenkarten sowie `Severity Distribution` starten als vollbreite minimierte Kopfzeilen mit rechtem Dreieck und koennen weiterhin individuell geoeffnet werden. 15 fokussierte Dashboard-/Interaktions-/Dreieckstests und der Client-/Server-Produktionsbuild sind erfolgreich. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+Verifizierte Client-Info-Titelleisteninteraktion vom 2026-09-04: Bei allen Mengen-, Fakten- und Donutkarten minimiert beziehungsweise maximiert ein Klick auf eine beliebige Stelle der gesamten Titelleiste den Karteninhalt. Der bestehende zugaengliche Pfeil-Button bleibt fuer Tastaturbedienung und `aria-expanded` erhalten; die gemeinsame Hoverflaeche macht die vergroesserte Klickzone sichtbar. 13 fokussierte Dashboard-/Interaktionstests, Local-only- und Designpruefung sowie der Client-/Server-Produktionsbuild sind erfolgreich. Der Gesamtlauf bestaetigt 780 bestandene Tests; genau eine unabhaengige statische Data-Hub-Open-Regression erwartet weiterhin die alte einzeilige Quelltextformatierung der funktional vorhandenen mehrzeiligen `dashboard`-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
+Verifizierte DB-Structure-Neugestaltung vom 2026-09-04: Die Datenbankansicht besitzt nun eine klare Informationshierarchie aus Einordnung und Schemaaktionen, vier kompakten Kennzahlen, fachlich beschriebenen Verarbeitungslayern und progressiv aufklappbaren Tabellendetails. Tabellen zeigen Spalten, Typen, Constraints und Beziehungen in strukturierten Inter-Zeilen; `Expand all` beziehungsweise `Collapse all` steuert die gesamte Ansicht. Segmente und Kacheln verwenden die gemeinsame transparente beziehungsweise flache, eckige Designsprache ohne Legacy-Akzentkontur, Schatten oder Monospace-Sondertypografie. Responsive Regeln erhalten die vollstaendige Lesbarkeit auf schmalen Viewports. Zwölf fokussierte Layout-, Interaktions-, Inset-, Typografie- und Kachelvertragstests, Local-only- und Designpruefung sowie der Client-Produktionsbuild sind erfolgreich. Der Gesamtlauf bestaetigt 783 bestandene Tests; zwei unabhaengige Regressionen betreffen weiterhin die einzeilige Data-Hub-Quelltextformatierung und eine parallel geaenderte GPO-Evaluationserwartung, 8 optionale PostgreSQL-Tests wurden uebersprungen. Der Server-Produktionsbuild ist durch eine fachfremde parallele Syntaxaenderung in `gpo-policy-evaluation-service.ts` blockiert. Keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen.
+
Ziele:
- Filter aus normalisierten Rollen und tatsächlichen Datenwerten erzeugen.
@@ -793,6 +869,33 @@ Abnahmekriterien:
- Unsichere Matches werden nicht automatisch als identisch gespeichert.
- Benutzerbestätigungen können als lokale Mappingregel wiederverwendet werden.
+#### Geplantes Arbeitspaket: faire Vergleiche bei fehlenden Folgequellen
+
+Ziel ist eine belastbare Fortschrittsaussage, auch wenn ein Kunde beim naechsten Timeslot nicht mehr alle bisherigen Scanner- oder GPO-Quellen liefert. Fehlende Evidenz darf weder als Verbesserung noch als Behebung erscheinen.
+
+Verbindliches Fachmodell:
+
+- Jede im Projekt erwartete Quelle besitzt je Timeslot genau einen Evidenzzustand: `observed-current` (im aktuellen Stand neu erhoben), `carried-forward-awaiting-revalidation` (letzter bekannter Stand, aktuell nicht erneut gemessen) oder `retired-out-of-scope` (ausdruecklich ab einem Stichtag aus dem Scope genommen).
+- Fehlt eine zuvor erwartete Quelle, werden ausschliesslich ihre noch offenen Finding-/Review-Verpflichtungen fortgeschrieben. Der alte Scan, die alte GPO-Beobachtung und deren Zeitstempel werden nicht als aktuelle Messung in den neuen Timeslot kopiert; Original-Timeslot, Quelltool, letzter Beobachtungszeitpunkt und Alter bleiben sichtbar.
+- Ein neuer Lauf derselben Quelle und desselben Scopes ersetzt den Fortschreibungszustand. Erst dann darf die Vergleichsengine `neu`, `weiterhin vorhanden`, `behoben` oder `wieder aufgetreten` fuer diese Quelle verifizieren.
+- Das ausdrueckliche Beenden einer Quelle ist eine eigene, auditierbare Aktion mit Akteur, Wirksamkeitsdatum und Begruendung. Es loescht keine Historie und ist nicht mit dem normalen Auswahlhaekchen beziehungsweise Bookmark gleichzusetzen.
+- GPO- und andere umgebungsbezogene Rohbeobachtungen bleiben als historische letzte Evidenz erhalten, werden aber ohne aktuellen Import nicht neu bewertet. Fortgeschrieben werden offene Findings und Arbeitsverpflichtungen, nicht behauptete aktuelle Konfigurationen.
+
+Vergleich und Score werden getrennt ausgewiesen:
+
+1. **Gemessener Fortschritt** verwendet nur die Schnittmenge der im Basis- und Ziel-Timeslot aktuell beobachteten, fachlich vergleichbaren Quellen.
+2. **Gesamtexposition / offener Backlog** umfasst aktuelle Findings plus fortgeschriebene, noch nicht erneut verifizierte Findings. Fortgeschriebene offene Risiken behalten ihr Risikogewicht, damit das Weglassen eines Scans den Score nicht verbessert.
+3. **Evidence Coverage / Freshness** zeigt separat, welcher Anteil aktuell gemessen, fortgeschrieben oder bewusst aus dem Scope genommen ist. Score und Abdeckung duerfen nie zu einer einzigen scheinbar praezisen Zahl verschmelzen.
+
+Vorgesehene Abnahmekriterien:
+
+- Ein fehlender Folgescan erzeugt weder `behoben` noch eine automatische Scoreverbesserung.
+- Gemeinsam vorhandene Quellen liefern weiterhin einen normalen, reproduzierbaren Fortschrittsvergleich.
+- Fortgeschriebene Findings sind optisch und maschinenlesbar von aktuell bestaetigten Findings getrennt und zeigen Quelle, Ursprungs-Timeslot und Alter.
+- Ein spaeterer aktueller Scan beendet die Fortschreibung deterministisch und erzeugt den korrekten Lebenszyklus.
+- `retired-out-of-scope` erfordert eine ausdrueckliche, auditierte Entscheidung; historische Findings bleiben erhalten.
+- Scanner, GPOs und spaetere Tools benutzen denselben generischen Quellenzustandsvertrag, ohne toolbezogene Sonderlogik in React.
+
### Phase 9 – Fachliche Persistenzschnittstelle
Status: abgeschlossen
@@ -826,6 +929,13 @@ Verifizierter Abschlussstand vom 2026-07-17:
- Verträge, Transaktionsgrenzen, Konfliktregeln und Backendübergang sind in docs/PERSISTENCE_BOUNDARY.md dokumentiert.
- 33 Testdateien mit 91 Tests, Local-only- und Architekturprüfung sowie Produktionsbuild laufen erfolgreich.
+Nachtraeglicher verifizierter UI-Integrationsstand vom 2026-09-06:
+
+- Die in FindingReader gepflegten Workflowdaten werden nicht mehr ausschliesslich im Browser gespeichert. Kanonische Finding-Vorkommen tragen ihre stabile Datenbankidentitaet bis in jede Work-Projektion; alle Projektionen desselben Vorkommens teilen einen Review.
+- Bookmark, exakter UI-Status, kanonischer Workflowstatus, Prioritaet, Owner/Team, Due Date, Prerequisites, Required Access/Roles, Next Step, Evidence/Acceptance Criteria, Comment und die Marker Question Needed, Permission Blocked, Quick Win, External Team sowie Not Relevant werden ueber die bestehende Review-API mit optimistischer Revision persistiert.
+- Vorhandene datenbankgestuetzte Reviews haben beim Laden Vorrang. Ein bisher nur lokal vorhandener Review bleibt erhalten, wird auf alle Projektionen desselben Vorkommens vereinheitlicht und beim naechsten verbundenen Laden ohne bestehenden Datenbankreview migriert. Fuer rein lokale, noch nicht kanonisch persistierte Importe bleibt die Browserablage der sichere Rueckfall.
+- Die Erweiterung nutzt das vorhandene JSONB-Reviewobjekt und benoetigt keine SQL-Migration. 43 fokussierte synthetische Roundtrip-, Repository-, Projektions-, Scope- und API-Tests, 825 Standardtests, Local-only-/Designpruefung sowie Client-/Serverbuild sind erfolgreich; 8 optionale PostgreSQL-Tests wurden uebersprungen und keine realen Findinginhalte gelesen.
+
Abnahmekriterien:
- React führt kein SQL aus.
@@ -1206,6 +1316,8 @@ Abnahmekriterien:
Status: in Arbeit
+Zwischenstand 2026-09-06 (Baseline-Vollreimport): Der bestaetigte Delete-Pfad entfernt nun auch ausschliesslich reproduzierbare Policy-Evaluations- und Finding-Ketten, die die geloeschte Baselineanalyse referenzieren. Kundenimporte, GPO-Beobachtungen, Environment Profiles und Snapshotaggregationen bleiben erhalten. Damit ersetzt diese Entscheidung die fruehere Delete-Sperre fuer bereits verwendete Baselines. Vor der produktiven Loeschung wurde der kanonische PostgreSQL-Bestand als Custom-Format gesichert und der Dumpkatalog gelesen. Der letzte blockierte Baselineeintrag wurde geloescht; der Katalog ist leer und 51 GPO-Beobachtungen sind weiterhin vorhanden. Der Neuimport selbst erfolgt anschliessend durch den Benutzer.
+
Ziele:
- Scannerinformationen ausserhalb einzelner Findings verlustfrei und mit Quellprovenienz erfassen.
@@ -1232,8 +1344,26 @@ Abnahmekriterien:
### Phase 13B – GPO-Backup- und Microsoft-Baseline-Analyse
+Verifizierter Zwischenstand 2026-09-06 (Benchmark-Semantik): Evaluator 1.3.3 erzeugt `Passed` oder `Failed` ausschliesslich aus einer zur beobachteten Umgebung passend ausgewaehlten Microsoft-Security-Baseline mit vorhandenem, technisch vergleichbarem Sollwert. Ein vorhandener Sollwert ohne Kundenwert ist `Failed`; identische Werte sind `Passed`, abweichende Werte `Failed`. Leere Baselinezeilen werden nicht bewertet, nicht unterstuetzte Werte bleiben Review/Warning und werden nie zu Pass/Fail umgedeutet. Security-Template-Registrywerte behalten Typ und Wert im Vergleich. Ausschliesslich Dummy wurde neu ausgewertet: 363 Failed, 13 Passed und 8 Review/Warning; 0 Pass/Fail-Zeilen ohne Baselinewert. 831 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Phase 13B bleibt in Arbeit.
+
Status: in Arbeit
+Verifizierter Zwischenstand 2026-09-06 (baseline-getriebener Soll-/Ist-Vergleich): Evaluator 1.3.1 startet je aktiver Microsoft-Baselineanalyse bei deren technisch aufgeloesten Empfehlungen. Ein identischer typisierter Ist-Wert wird `configured_match`/Passed, ein abweichender oder im importierten GPO-Backup fehlender Ist-Wert wird `confirmed_configured_deviation`; Einstellungen ohne Baselineempfehlung erzeugen kein Bewertungsergebnis. Mehrere Baselines werden unabhaengig ausgewertet und nicht mehr als mehrdeutige globale Betriebssystemauswahl blockiert. Konflikte, indeterminierte Werte und unvergleichbare Typen bleiben Review. Die neutrale Auswertung behauptet weder Wirksamkeit noch Severity und bleibt fuer die Finding Factory `ineligible`. Migration 020 erlaubt dafuer baseline-gebundene Ergebnisse ohne erfundenen Aggregationszustand; Work zeigt fehlende und vorhandene Vergleiche einzeln mit kurzem Baseline-Namen. Ein deduplizierter GPO-Reimport startet die aktuelle Auswertung erneut. Nach Datenbanksicherung wurde ausschliesslich der freigegebene Dummy neu ausgewertet: 3.638 Vergleiche, 55 Passed, 3.556 Abweichungen (davon 3.483 fehlende Ist-Werte) und 27 Review-Faelle. Kein anderer Mandant wurde ausgewertet. 821 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Phase 13B bleibt fuer die Aufloesung der 27 Review-Faelle, weitere Preference-CSEs und Exportdetails in Arbeit.
+
+Verifizierter Zwischenstand 2026-09-06 (direkte Work-Anzeige): Baseline-Abweichungen werden in der regulaeren Work-Projektion als `Failed` dargestellt und erscheinen im eigenen Blatt sowie in der Kategorie und Quelle `GPOs`; passende Werte bleiben `Passed`, unentscheidbare Vergleiche `Investigate`. Damit greift der normale Work-Standardfilter fuer Abweichungen, ohne dass die separate Policy-Analyseansicht fuer die taegliche Findingsicht erforderlich ist. Beim Oeffnen werden ausschliesslich Ergebnisse des aktuellen Evaluators beruecksichtigt und pro GPO-Backup der vollstaendigste Baseline-Lauf gewaehlt; ein spaeterer Teillauf kann die vollstaendige Auswertung nicht mehr verdraengen. Der leere Clientzustand enthaelt keinen Verweis mehr auf die separate View. 825 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Ausschliesslich synthetische Regressionen verwendet; keine Kundendaten oder Persistenz veraendert. Phase 13B bleibt in Arbeit.
+
+Verifizierter Zwischenstand 2026-09-06 (direkte Result-DB-Anzeige): Der Local- und PostgreSQL-Read-Pfad projiziert nun jeden aktuellen, deterministischen Baselinevergleich direkt als `policy_deviation` unter dem Source Tool `GPOs`. Abweichung, Uebereinstimmung, Nichtanwendbarkeit und Review bleiben als `fail`, `pass`, `not_applicable` und `warning` getrennt; neutrale Vergleiche behalten Severity `unknown`. Ein bereits durch die Finding Factory angereicherter Vergleich ersetzt seine neutrale Zeile und wird ebenfalls unter `GPOs` gefuehrt, sodass keine Duplikate entstehen. Rohbeobachtungen bleiben ausschliesslich `internal-analysis`. Die PostgreSQL-Projektion materialisiert den grossen Evaluation-Run einmal je aktiver Aggregation statt ihn je Ergebniszeile erneut aus JSONB zu entpacken. Inhaltsfreie Laufzeitpruefung auf dem freigegebenen Dummy: Source Tool `GPOs` vorhanden, 3.638 aktuelle Vergleiche und 3.583 Abweichungen; Listen- und Facettenabfragen jeweils unter 0,5 Sekunden. 826 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Persistenzmutation und keine Einsicht in Kundeninhalte; Phase 13B bleibt fuer Review-Faelle, weitere Preference-CSEs und Exportdetails in Arbeit.
+
+Verifizierter Zwischenstand 2026-09-06 (Evaluation ohne Zusatzklick): Der bestehende automatische Jobpfad fuehrt nach Parsing und Identity-Analyse unmittelbar Snapshotaggregation, Baseline-Evaluation und Finding Factory aus und setzt den Importjob erst danach auf `succeeded`. Der irrefuehrende `Evaluate`-Button wurde aus erfolgreichen beziehungsweise partiellen GPO-Zeilen entfernt; `Retry` bleibt ausschliesslich fuer fehlgeschlagene Importjobs. Der vorhandene projektgebundene Evaluate-Endpunkt bleibt als technische Recovery-Grenze erhalten, ist aber kein regulaerer UI-Arbeitsschritt. Der Progressdialog bleibt waehrend Queue, Import und automatischer Auswertung geoeffnet. Ein neuer Regressionstest sichert die Reihenfolge Analyse -> automatische Evaluation -> Jobabschluss. 827 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Bestandsdaten veraendert; Phase 13B bleibt in Arbeit.
+
+Zwischenstand 2026-09-06 (einzelnes GPO-Delete): Die bisher auf Dead-Letter-Artefakte begrenzte Loeschung gilt nach ausdruecklicher Bestaetigung fuer jeden beendeten GPO-Import. Abhaengige Policy-Snapshot-Aggregationen werden als reproduzierbare Derivate invalidiert; ihre Evaluationen und Findings folgen transitiv. Der Timeslot, andere Quellen und das Environment Profile bleiben erhalten. Laufende oder eingereihte Jobs blockieren die Mutation. Die UI bietet Delete direkt in jeder GPO-Zeile. Keine Migration und keine Mutation des kanonischen Bestands; Phase 13B bleibt in Arbeit.
+
+Zwischenstand 2026-09-06: Die automatische GPO-Pipeline nutzt zuerst beobachtete Betriebssystem-/DC-Daten aus dem EnvironmentSnapshot desselben Timeslots, mit Quellenreferenzen; Functional Levels sind kein Betriebssystemersatz. GPMC-CoreSettings und verschachtelte GPReport-Identitaeten werden nun gelesen. Der speicherbegrenzte SAX-Metadatenparser verarbeitet groessere Backups; eine synthetische Regression mit 2300 GPOs prueft ZIP und Ordnertransport. Security Templates und Advanced Audit erhalten auf Kunden- und Baselinenseite gemeinsame native Zielidentitaeten neben Registry.pol. Nach Import folgen bei eindeutigen Voraussetzungen Aggregation, Evaluation und die weiterhin freigabegesicherte Finding Factory; Work projiziert aktuelle Bewertung und Baselinewert neben den Beobachtungen. Evaluate ersetzt den obligatorischen View-Zwischenschritt.
+
+Verifiziert auf dem ausdruecklich freigegebenen Dummy: erneute Verarbeitung des erhaltenen Originals erfolgreich, 51 aktuelle Beobachtungen und 50 persistierte Bewertungsergebnisse. Diese stehen in Review, nicht auf bestaetigter Uebereinstimmung: Backup-ID/-zeit und Setvollstaendigkeit sind nicht ausreichend belegt; die vorhandene Baselineanalyse ist unvollstaendig. Das referenzierte Original der passenden Baseline fehlt sowohl im konfigurierten LocalAppData-Speicher als auch im vorhandenen Workspace-Speicher. Migration 019 erweitert nur erlaubte Policy-Zielarten; vorher wurde ein Custom-Format-Backup des kanonischen Bestands erstellt und per pg_restore --list auf Lesbarkeit geprueft, kein Restore behauptet. Kundenoriginale und bestehende Runs bleiben unveraendert. Keine anderen Kunden neu verarbeitet. Keine visuelle Browserabnahme; Phase 13B bleibt offen.
+
+Aktueller verifizierter Zusatzstatus vom 2026-09-04: Die nachtraeglich eingefuehrte Regelkatalog-Grenze blockiert den urspruenglich vorgesehenen neutralen Feinvergleich zwischen importierter Microsoft Security Baseline und technisch eindeutig aufgeloesten GPO-Einstellungen nicht mehr. Fehlt fuer alle anwendbaren Kontexte eine Katalogregel, verwendet Evaluator 1.2.0 den importierten Baselinewert direkt mit einem typgetreuen Equality-Comparator und erzeugt reproduzierbar `configured_match` oder `confirmed_configured_deviation`. Eine solche neutrale Abweichung besitzt keine erfundene Severity, keine Risikoregel und bleibt fuer die Finding Factory `ineligible`; erst eine eindeutige freigegebene Katalogregel darf staerker/schwaecher, Abhaengigkeiten, Risiko und Finding-Freigabe ergaenzen. Teilweise ADMX-Metadaten blockieren den exakten Vergleich einer bereits aufgeloesten Einstellung nicht, bleiben aber als Diagnose sichtbar; mehrdeutige oder nur fuer einen Teil der Kontexte passende Regeln, unvollstaendige Kundensnapshots, Baseline-Mehrdeutigkeit, Wertkonflikte und nicht vergleichbare Typen bleiben fail-closed in Review. Die Aktionsprojektion erkennt Evaluationen aelterer Engineversionen nicht mehr als aktuellen Abschluss und bietet fuer denselben Snapshot und dieselbe Baseline eine neue 1.2-Auswertung an. 36 fokussierte Policy-Tests und alle betroffenen GPO-Tests sind erfolgreich. Im Gesamtlauf bestanden 785 Tests; ein fachlich unabhaengiger bestehender statischer Data-Hub-Test erwartet eine einzeilige Quelltextformatierung, waehrend die bereits vorhandene uncommittete UI-Aenderung denselben Ablauf mehrzeilig schreibt; 8 optionale PostgreSQL-Tests wurden uebersprungen. Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt fuer den noch fehlenden Baseline-only/Subject-missing-Vergleich, fachliche Kataloganreicherung, weitere Preference-CSEs und Exportdetails in Arbeit.
+
Aktueller verifizierter Zusatzstatus vom 2026-09-03: Die bislang fehlende GPO-Anbindung an Work und Result DB ist als additives, timeslotgebundenes Readmodell geschlossen. Jede aktuelle rohe `PolicyObservation` wird als eigener Quelltyp `policy-observation` mit Assessment-, Artefakt-, Backup-, Parser-, Reducer-, Identity-, Wert-, Diagnose- und Locator-Provenienz projiziert. Diese Datensaetze bleiben fachlich `informational`, zeigen IOE und Deviation als nicht anwendbar und werden auch unter dem Result-DB-Standardfilter `Deviation = Yes` als Kontext sichtbar; nur die Finding Factory darf weiterhin eine echte `policy_deviation` erzeugen. Work fuegt `Group Policy · Observations` als eigenes Blatt hinzu und nimmt dieselben Zeilen in `All Records` auf, sodass `Source: Scan` dort `Group Policy` anbietet. Der freigegebene Dummy-Timeslot liefert ueber die laufende PostgreSQL-API 452 Scannerabweichungen plus 51 GPO-Beobachtungen, insgesamt 503 sichtbare Resultate. 13 fokussierte Tests und der Gesamtlauf mit 781 bestandenen sowie 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine SQL-Migration und keine Veraenderung der importierten Originaldaten; Phase 13B bleibt fuer fachliche Identity-/Regelkataloge und bestaetigte Policy-Findings in Arbeit.
Aktueller verifizierter Zusatzstatus vom 2026-09-03: Die bislang implementierte, aber nicht erreichbare Policy-Analyseoberflaeche ist nun aus dem Data-Hub-Clientdetail zugreifbar. Eine erfolgreiche GPO-Quellenzeile verwendet keine irrefuehrende deaktivierte Scanner-Auswahlbox mehr, sondern eine eigene Quellenmarkierung und eine `View`-Aktion. Diese oeffnet die projektgebundene GPO-Analyse mit Reprocessing, Environment Profiles, Aggregation, Evaluation, Finding Factory, aktueller Summary, Historie und Review Queue; zur Stammdatenansicht kann direkt zurueckgewechselt werden. `Source: Scan` bleibt fachlich auf Scanner-Runs begrenzt. Sieben fokussierte Data-Hub-/Policy-UI-Tests, die Gesamtsuite mit 775 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only- und Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich. Keine API-, SQL- oder Persistenzaenderung; Phase 13B bleibt in Arbeit.
@@ -1251,7 +1381,7 @@ Aktueller verifizierter Zusatzstatus vom 2026-08-22: Der globale Microsoft-Secur
Ziele:
- GPMC-/`Backup-GPO`-Backups und Microsoft-Security-Baselinepakete deterministisch, sicher und nachvollziehbar analysieren.
-- Richtlinieneinstellungen technisch identifizieren, innerhalb eines konsistenten Kundensnapshots aggregieren, Konflikte erkennen und gegen alle vollständig geprüften technisch passenden Baselinekontexte bewerten.
+- Richtlinieneinstellungen technisch identifizieren, innerhalb eines konsistenten Kundensnapshots aggregieren, Konflikte erkennen und jede aktive importierte Baseline separat als nachvollziehbaren Soll-/Ist-Vergleich auswerten; Produkt- und Rollenfilter bleiben eine nachgelagerte Sicht statt einer globalen Importsperre.
- Nur bestätigte konfigurierte Abweichungen als normale Findings erzeugen; tatsächliche Wirksamkeit ohne Scope- oder RSoP-Evidenz niemals behaupten.
Gemeinsame und getrennte Grenzen:
@@ -1419,6 +1549,20 @@ Aktualisierung nach der Katalog-Ladegrenze vom 2026-09-03: Fachlich freigegebene
## 9. Bereits getroffene Architekturentscheidungen
+Festlegung 2026-09-06 (Phase 8, fehlende Folgequellen): Timeslotvergleiche trennen kuenftig gemessenen Fortschritt, Gesamtexposition und Evidence Coverage/Freshness. Fehlende erwartete Quellen werden nicht als behoben interpretiert. Offene Verpflichtungen werden mit Herkunft und Alter als `carried-forward-awaiting-revalidation` fortgeschrieben und bleiben scorewirksam; Rohbeobachtungen werden nicht als aktuelle Evidenz kopiert. Ein Scope-Ende ist ausschliesslich ueber eine begruendete, auditierte `retired-out-of-scope`-Entscheidung moeglich. Dieser generische Vertrag gilt fuer Scanner, GPOs und spaetere Tools und wird nicht ueber ein primaeres manuelles Auswahlhaekchen gesteuert.
+
+Festlegung 2026-09-06 (Phase 9/10, FindingReader-Reviews): Bearbeitbare Workflowdaten gehoeren zum kanonischen Finding-Review und damit in die ASSESSOR-Datenbank, nicht nur in Local Storage. Die stabile Occurrence-ID verbindet Aggregate und Quellansicht; Datenbankwerte gewinnen beim Laden, Local Storage bleibt Rueckfall und Migrationsquelle. Der exakte UI-Status wird additiv neben dem kanonischen Workflowstatus bewahrt; unbekannte kuenftige Marker bleiben bei Updates erhalten.
+
+Festlegung 2026-09-06 (Phase 13B, einzelnes GPO-Delete): Ein ausdruecklich bestaetigtes, projekt- und artefaktgebundenes Delete ist fuer beendete GPO-Importe zulaessig und entfernt neben der backendkontrollierten Originalkopie alle direkt oder transitiv davon abhaengigen Processing-, Identity-, Snapshot-, Evaluation- und Finding-Derivate. Eine Aggregation mit mehreren Quellen wird vollstaendig invalidiert, sobald eine ihrer Quellen geloescht wird; die uebrigen Quellimporte und das Environment Profile bleiben bestehen und koennen neu aggregiert werden. Queue-/Running-Jobs bleiben gegen Loeschung gesperrt. Die persistente Loesch-Outbox bleibt die Grenze zwischen relationalem Commit und Dateientfernung. Diese Festlegung ersetzt die Entscheidung vom 2026-07-21, Delete ausschliesslich fuer vollstaendig fehlgeschlagene GPO-Artefakte zuzulassen.
+
+Festlegung 2026-09-06 (Phase 13B, Baseline-Reimport): Eine ausdruecklich bestaetigte Baseline-Loeschung darf referenzierende, reproduzierbare Evaluation-/Finding-Derivate transitiv entfernen. Unveraenderliche Kundenquellen, GPO-Processing-Runs, Beobachtungen, Environment Profiles und Snapshotaggregationen werden dadurch nicht geloescht. Diese Reimportfunktion ersetzt die Entscheidung vom 2026-08-22, referenzierte Baselines grundsaetzlich zu sperren.
+
+Festlegung 2026-09-06 (Phase 12/13B, Datenschutzgrenze der Result DB): Die Result DB enthaelt kanonische Findings und ausschliesslich explizit freigegebene, nicht identifizierende Zusatzbeobachtungen. Eine versionierte tool-/propertybezogene Allowlist rekonstruiert nur kontrollierte Titel, Klassen und eng validierte Aggregate, Konfigurationszustaende oder technische Metadaten; Subject-Identitaet, Originalwert, Attribute, Asset, Abschnitt und Locator bleiben intern. Unbekannte beziehungsweise zukuenftige Tools behalten ihre regulaeren Findings im generischen Importpfad, ihre Zusatzfelder bleiben jedoch bis zur Datenschutzklassifikation fail-closed ausserhalb der Result DB. Rohe GPO-Policy-Beobachtungen sind nur noch im ausdruecklichen internen Analysemodus fuer Work/GPO Analysis lesbar; bestaetigte Policy-Findings bleiben Result-DB-faehig. Diese Festlegung supersediert die Entscheidung vom 2026-09-03, rohe GPO-Policy-Beobachtungen auch in der Result DB darzustellen.
+
+Festlegung 2026-09-06 (Phase 13B/13C, ausdruecklicher Nutzerwunsch): Vor Rueckfragen zum GPO-Zielkontext vorhandene Result-DB-/PingCastle-Umgebungsbeobachtungen im selben Assessment auswerten. Belegte DC-Betriebssystemkontexte duerfen mit Beobachtungsprovenienz automatisch entstehen; dies erweitert die bisherige ausschliesslich manuelle Profilwahl. Domain-/Forest-Functional-Level, Herkunft des Backups vom DC und Registry-Pfade allein beweisen weder Betriebssystemversion noch GPO-Anwendung auf DC/Member/Client. Gemischte oder unzureichend belegte Plattformen bleiben klaerungsbeduerftig. Technische Identitaeten gleichen konkrete Einstellungen ab, nicht GPO-Namen.
+
+Festlegung vom 2026-09-06 (Phase 11, lokaler Persistenzbetrieb): Der vorhandene Docker-Compose-Bestand `assessor-2_0` mit der Datenbank `assessor`, dem Container `assessor-2_0-postgres-1` und dem persistenten Volume `assessor-2_0_assessor-postgres-data` ist der einzige kanonische lokale ASSESSOR-Datenbestand fuer diesen Workspace. Lokale Starts verwenden ausschliesslich `127.0.0.1:5432`. Die Compose-Konfiguration bindet dieses Volume deshalb namentlich als `external`; bei fehlendem Bestand oder Portkonflikt muss der Start fehlschlagen, statt eine weitere ASSESSOR-Datenbank oder einen Ersatzport anzulegen. Diese ausdrueckliche Nutzerfestlegung ersetzt die bisherige implizite, verzeichnisabhaengige Compose-Projektidentitaet. Der interne Browser-/Backend-/PostgreSQL-Zielaufbau bleibt unveraendert.
+
| Datum | Entscheidung | Begründung |
| 2026-09-03 | Die verbindliche Client-Info-Startansicht expandiert nur `Assessment Status`; alle neun anderen Informationskarten starten minimiert. | Der Gesamtstatus bleibt ohne Interaktion sichtbar, waehrend die darunterliegende feste 3/2/2-Matrix und die rechte Rail als kompakte, stabile Navigation beginnen. Inhalte werden nicht entfernt und bleiben ueber die Standarddreiecke einzeln erreichbar. |
| 2026-09-03 | Minimierte Client-Info-Karten bleiben ueber die volle Breite ihrer festen Spalte gespannt. `Directory Overview` zeigt keine werkzeugspezifische PingCastle-Engine-Version mehr. | Collapse soll ausschliesslich die Hoehe reduzieren und darf die stabile Spaltengeometrie nicht veraendern. Die Directory-Karte beschreibt den Verzeichniszustand; eine Scanner-Engine-Version gehoert nicht zu diesem fachlichen Ueberblick und bleibt nur in der unveraenderten Provenienz erhalten. |
@@ -1697,6 +1841,10 @@ Abnahme 2026-08-23: 677 Standardtests bestanden, 8 optionale PostgreSQL-Integrat
## 10. Offene Entscheidungen
+Festgelegte Versionsentscheidung vom 2026-09-06: Die sichtbare ASSESSOR-Version ist die eigenstaendige Produktversion und wird nicht aus Parser-, Mapping-, Processing- oder GPO-Evaluatorversionen abgeleitet. `2.5.1` bezeichnet den aktuellen Produktstand; technische Komponentenstaende bleiben im About-Popup und in der Ergebnisprovenienz getrennt sichtbar. Produktversionen folgen Semantic Versioning: Patch fuer kompatible Korrekturen, Minor fuer neue kompatible Funktionen, Major fuer bewusst inkompatible Produkt- oder Datenvertragswechsel.
+
+Festgelegte Fachentscheidung vom 2026-09-06: Ein GPO-Benchmark darf nur dann `Passed` oder `Failed` liefern, wenn die passend ausgewaehlte Microsoft-Security-Baseline einen vorhandenen und technisch vergleichbaren Sollwert vorgibt. Kundenwerte ohne Microsoft-Sollwert werden nicht als Abweichung gewertet; leere Sollwerte entfallen, nicht unterstuetzte Sollwerte bleiben Review/Warning. Die spaetere optionale Darstellung reiner Kundenkonfigurationen als Info bleibt offen.
+
- Aufbewahrung oder bewusster Verzicht auf vollständige Originaldateien normaler Scannerimporte; für GPO- und Baseline-Reprocessing ist die unveränderte Aufbewahrung beschlossen
- Verschlüsselung der Datenbank beziehungsweise Anforderungen an Datenträgerverschlüsselung
- Verschlüsselung, Speicherort, Zugriffsschutz und Löschfristen des GPO-/Baseline-Artefaktspeichers
@@ -1714,6 +1862,20 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode
## 11. Risiken
+| Die Produktversion bleibt trotz funktionaler Aenderungen unveraendert oder wird mit einer technischen Komponentenfassung verwechselt; Frontend und Backend koennen zudem unterschiedliche Builds ausliefern. | Produktversion zentral aus dem Paket beziehen, im Markenblock zeigen, Buildzeit und Backend-Release im About-Popup ausweisen und die Backend-Produktversion ueber Health melden. Releaseprozess und Tests muessen die bewusste SemVer-Aenderung pruefen. |
+
+| Leere oder technisch nicht normalisierbare Microsoft-Baselinewerte koennten als Abweichung erscheinen und die Work-Liste mit nicht belastbaren Findings aufblasen. | Baselinezeilen ohne Sollwert vor der Evaluation ausschliessen; Pass/Fail nur bei vorhandenem vergleichbarem Baselinewert zulassen; nicht unterstuetzte Werte als Review/Warning fuehren und synthetisch sowie per inhaltsfreier Zaehlerpruefung absichern. |
+
+Festgelegtes Vergleichsrisiko vom 2026-09-06: Wenn eine im Folgetimeslot fehlende Quelle still als nicht mehr vorhanden gilt, erscheinen offene Risiken faelschlich behoben und Score sowie Fortschritt lassen sich durch weniger Evidenz verbessern. Gegenmassnahme: erwartete Quellen explizit zustandsbehaftet fuehren, nur aktuell beidseitig beobachtete Quellen fuer gemessenen Fortschritt verwenden, offene letzte Findings separat und scorewirksam fortschreiben sowie Coverage/Freshness sichtbar ausweisen. Rohbeobachtungen duerfen dabei nicht als aktuelle Messung dupliziert werden.
+
+Festgelegtes Review-Persistenzrisiko vom 2026-09-06: Dieselbe Finding-Occurrence kann in mehreren Work-Blaettern unterschiedliche Anzeige-IDs besitzen; eine rein an diese IDs gebundene Browserablage kann Owner, Termine und Massnahmen auseinanderlaufen oder bei Browserwechsel verloren gehen. Gegenmassnahme: kanonische Occurrence-/Definition-IDs in die Projektion tragen, alle Projektionen synchronisieren, ueber die Same-Origin-API optimistisch versioniert speichern und die lokale Ablage nur als Rueckfall/Migrationsquelle behandeln.
+
+Festgelegtes Datenschutzrisiko vom 2026-09-06: Scanner-Zusatzinformationen und rohe Policy-Beobachtungen koennen Personen-, Konto-, Domain-, Host-, GPO-, Pfad- oder andere kundenidentifizierende Werte enthalten. Gegenmassnahme: Die Result-DB-Projektion arbeitet fail-closed mit einer versionierten Allowlist und engen Wertvalidatoren, verwendet kontrollierte Metadaten statt Quelllabels und entfernt Identitaeten, Originalwerte, Attribute und Locator. Der JSONL-Export prueft die Klassifikation erneut. Neue Tools liefern weiterhin kanonische Findings, aber keine ungeprueften Zusatzfelder; deren Freigabe erfordert eine synthetisch regressionsgepruefte Policy-Erweiterung.
+
+Offen 2026-09-06 (Phase 13B): Die automatische Kontextableitung unterstuetzt derzeit belegte DC-Betriebssysteme; umfassende Member-/Client-/Produktableitung und kontextspezifische Baseline-Teilpakete sind nicht abgeschlossen. Ausgewaehlte/unvollstaendige Backups bleiben nach der bestehenden Bewertungsgrenze Review; ein neutraler Teilmengenvergleich ohne Vollstaendigkeitsaussage ist separat zu entwerfen. Fehlende Baselineoriginale verhindern Reprocessing aus Originalbytes, auch wenn alte Analysen noch lesbar sind. Erforderlich sind Wiederbereitstellung der identischen Originale oder ein neuer expliziter Import; keine Ersatzdaten und kein stiller Speicher-/Datenbankwechsel.
+
+Festgelegtes Betriebsrisiko vom 2026-09-06: Verzeichnisabhaengige Compose-Projektnamen oder spontane Portausweichungen koennen mehrere auseinanderlaufende ASSESSOR-Datenbanken erzeugen und die App unbemerkt mit einem anderen Datenstand verbinden. Gegenmassnahme: `assessor-2_0` und `assessor-2_0_assessor-postgres-data` sind in Compose und `AGENTS.md` kanonisch gebunden; das Volume ist extern, Port `5432` verbindlich, alternative ASSESSOR-Datenbanken und Fallbackports sind untersagt. Vor Persistenzmigrationen oder destruktiven Eingriffen ist ein verifiziertes Backup erforderlich; fremde Docker-Bestaende bleiben unberuehrt.
+
| Risiko | Gegenmaßnahme |
| Eine spaetere Kartenrefaktorierung kann wieder alle Client-Info-Karten standardmaessig oeffnen und damit die vereinbarte kompakte Startansicht verlieren. | Den Startzustand an jeder konkreten Karteninstanz explizit setzen und statisch pruefen: neun `initiallyExpanded={false}` sowie genau ein nicht minimierter `Assessment Status`; die gemeinsame Komponente bleibt fuer gezielte Wiederverwendung konfigurierbar. |
| Eine minimierte Client-Info-Karte kann durch intrinsische Flexbreite schmaler als ihre Spalte werden; werkzeugspezifische Provenienz kann ausserdem erneut in einen fachlichen Verzeichnisueberblick geraten. | Collapsed-Karten explizit auf `width: 100%` setzen und diese Geometrie regressionspruefen. `directoryFacts` auf fachliche Directory-Felder begrenzen; Scanner-Engine-Versionen bleiben in der Quellprovenienz statt in `Directory Overview`. |
@@ -1811,6 +1973,7 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode
| Eine lokale ScanRun-Abwahl koennte beim Wechsel des Timeslots unbemerkt weiterwirken, neue Importe ausschliessen oder bei Mehrfachauswahl die bestehende Vergleichsschnittmenge umgehen. | Ausschliesslich ausgeschlossene Run-IDs lokal speichern, den Zustand beim Mandanten-/Timeslot-Neueinstieg und nach Loeschungen bereinigen und neue Runs dadurch standardmaessig einschliessen. Fuer `Open` zuerst je Timeslot die lokale Auswahl projizieren und erst danach unveraendert die sichere gemeinsame Werkzeugmenge berechnen; ohne verwertbaren Run bleibt `Open` gesperrt. |
| Work und Graph koennten bei getrennten lokalen Filterzustaenden unterschiedliche Findingmengen zeigen oder werkzeugspezifische Facetten unvollstaendig abbilden. | Beide Ansichten ausschliesslich aus dem gemeinsamen AppProvider-Zustand und `useFilteredRecords()` speisen; im Graph dieselben Search-/Sheet-/Facet-Controls wiederverwenden und lokale Graphfilter durch Strukturtests ausschliessen. Nur rein praesentative Graphzustaende lokal halten. |
| Ein dichter Netzwerkgraph kann bei vielen Findings durch zu viele Labels, Kanten oder unkontrollierte Layoutberechnungen unlesbar beziehungsweise traege werden; die gepunktete Graphflaeche kann im Lightmode zu dominant wirken. | Deterministisches lineares Clustering statt quadratischer Laufzeit verwenden, Clusterabstaende und Karten kompakt begrenzen, Labels standardmaessig auf Auswahl/Hover reduzieren, Fit/Zoom bereitstellen und Graphdaten rein aus der bestehenden gefilterten Projektion ableiten. Punktfarbe und Knotenrollen ausschliesslich ueber semantische Dark-/Light-Tokens steuern und das Muster strikt auf die Graphansicht begrenzen. |
+| Ein einzelnes GPO-Delete koennte waehrend der Verarbeitung mit dem Worker konkurrieren oder nach einer bereits erfolgten Evaluation verwaiste Snapshot-/Finding-Derivate hinterlassen. | Queue-/Running-Jobs an der Repository-Grenze blockieren. Vor dem Artefaktdelete jede Snapshotaggregation entfernen, die eine Identity-Analyse dieses Artefakts verwendet; relationale Cascades beziehungsweise die identische lokale Projektion entfernen Evaluationen und Findings. Timeslot, andere Imports und Environment Profile erhalten und die Dateikopie ueber die persistente Outbox entfernen. |
| Ein in der Timeslot-Zeile platzierter Delete-Button koennte versehentlich den gesamten Mandanten oder nur sichtbare Scanzeilen loeschen und GPO-/Evidenzreste hinterlassen. | Mandanten- und Timeslot-Loeschung strikt trennen. Timeslot-Delete verlangt Projekt- und Assessment-ID plus Cascade-Bestaetigung an der Repository-Grenze und entfernt den Assessment-Teilbaum; der Dialog nennt den betroffenen Stichtag und bestaetigt ausdruecklich, dass Mandant und andere Timeslots erhalten bleiben. |
| Mehrere Timeslots besitzen unterschiedliche Scanner- oder GPO-Abdeckung; ein ungefiltertes Oeffnen wuerde fehlende Quellen als fachliche Veraenderung interpretieren und Aepfel mit Birnen vergleichen. | Vor der Mehrfachprojektion pro Timeslot die sicher erkannte Quellenmenge bilden und nur deren Schnittmenge weiterreichen. Generische, unbekannte oder gemischte Werkzeugidentitaeten nicht automatisch gleichsetzen; GPO separat als Assessment-Quelle behandeln und fehlende beziehungsweise ausgeschlossene Quellen sichtbar nennen. |
| Ein Delete-Button koennte eine bereits fuer Policy-Evaluationen verwendete Microsoft-Baseline oder nur deren sichtbare Tabellenzeile entfernen und dadurch Evidenz beziehungsweise Artefakte inkonsistent hinterlassen. | Expliziten Bestaetigungsdialog und bestaetigungspflichtigen DELETE-Vertrag verwenden; Referenzen in Local- und PostgreSQL-Persistenz vor der Mutation blockieren, abhaengige Klassifikationen und Analysen atomar mit dem Katalogeintrag entfernen und das danach unreferenzierte private Speicherobjekt best-effort bereinigen. |
@@ -1948,6 +2111,33 @@ Diese Entscheidungen werden erst getroffen, wenn die jeweilige Phase ansteht ode
| 2026-09-10 | Phasen 7/13A fuer gemischte Defender-Timeslots korrigiert: Work bestimmt den Titel jedes Datensatzes anhand seiner Scannerprovenienz und des deklarativen Titel-Headers, sodass Defender-Vorkommen im gemeinsamen All-Records-Blatt die CVE statt Device-Name oder IP zeigen. Client Info behaelt bei mehreren Scannern die allgemeine Uebersicht und bietet Defender zusaetzlich als eigenen Tab mit den vorhandenen CVE-, Device- und Site-Sichten an. 19 fokussierte Dashboard-, Titel- und Graphregressionen erfolgreich. Keine API-, SQL-, Profil- oder Persistenzmigration; Phasen 7 und 13A bleiben abgeschlossen. |
| 2026-09-10 | Phase-13A-Verarbeitungsvertrag fuer Defender-Importe korrigiert: Die Kompatibilitaetspruefung verwendet nun den tatsaechlich persistierten `processedWith.profileId` statt einer eventuell abweichenden erkannten Werkzeug-ID. Dadurch werden registrierte Defender-Profile 1.0.0 als aktuell bewertet; unbekannte Profil-/Versionspaare bleiben fail closed. Die Korrektur ist read-only fuer vorhandene Importdaten und benoetigt keinen Reimport oder Datenbankeingriff. 17 fokussierte Import-/Kompatibilitaetstests sowie der Gesamtlauf mit 766 bestandenen und 8 uebersprungenen optionalen PostgreSQL-Tests, Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich; Phase 13A bleibt abgeschlossen. |
| 2026-09-10 | Microsoft Defender for IoT vulnerability imports and views umgesetzt: Profil und Source Extractor 1.0.0 erweitern die generische Excel-/CSV-Pipeline; Device-Identitaeten, CVE-Definitionen, Device-mal-CVE-Vorkommen, rohe Sensorbeobachtungen und Aggregate-only-Zahlen bleiben getrennt. Client Info bietet CVE-, Device- und Site-Sichten mit Evidenz- und Reconciliation-Drill-down. Summary-only-Quellen bleiben ohne erfundene Findings viewable. 33 fokussierte synthetische Tests sowie 764 Standardtests, 8 uebersprungene optionale PostgreSQL-Tests, Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine API-, SQL- oder Persistenzmigration; Phasen 6, 7 und 13A bleiben abgeschlossen. |
+| 2026-09-06 | Phase 7: GPO-Work-Kacheln gegen ueberlappende lange Registry- und Policy-Pfade abgesichert. `group-policy`-Kacheln tragen eine explizite Toolkennung und erlauben im Titel sichere Umbrueche innerhalb ungeteilter Pfadsegmente; Titel bleiben in ihrer mittleren Gridspalte und ueberdecken weder Bookmark noch Nachbarkachel. Andere Findingtitel behalten die bestehende wortbasierte Typografie. 42 fokussierte synthetische Tests, Designpruefung und Client-Produktionsbuild erfolgreich; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
+| 2026-09-06 | Phase 7/13B: GPO-only-Timeslotfreigabe auf alle Clientansichten vereinheitlicht. Die zentrale Scope-Regel akzeptiert mindestens eine Scanner-Run-ID oder Assessment-ID; Client Info, Work, Result DB und Pathfinder behandeln damit reine GPO-Timeslots als ausgewaehlt, waehrend Datahub und DB Structure scannertypunabhaengig bleiben. Result-DB-Laden und -Export verwenden denselben projekt- und assessmentgebundenen Scope. Kein automatisches Beimischen anderer Timeslots oder Scannerlaeufe. 25 fokussierte synthetische Tests, Designpruefung und Client-Produktionsbuild erfolgreich; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
+| 2026-09-06 | Phase 7: Englisch als verbindliche Sprache fuer saemtliche nutzerseitig sichtbaren ASSESSOR-Texte festgelegt, einschliesslich Navigation, Labels, Aktionen, Status-, Lade-, Leer-, Fehler-, Bestaetigungs- und Dialogtexte sowie kuenftiger Funktionen. Deutsche Texte bleiben auf interne Dokumentation, Kommentare oder ausdruecklich angeforderte Exportinhalte begrenzt. Den verbliebenen deutschen Ladehinweis der Data-Hub-Historie auf `Loading clients …` umgestellt. Keine Daten-, API-, Persistenz- oder Schemaaenderung. |
+| 2026-09-06 | Phase 7: Gemeinsamen markenfreien Panel-Ladezustand eingefuehrt. Der konkrete Ladetext wird mit der aus den Processing-Pop-ups wiederverwendeten quadratischen Ladeanimation direkt daneben im verfuegbaren Inhaltsbereich zentriert. Client Info, DB Structure, Result DB, Data-Hub-Historie, Timeslot-Liste und Policy Analysis verwenden denselben Vertrag, eingebettete Bereiche in einer kompakten Variante. Fehler-, Leer- und Operationszustaende bleiben getrennt. 835 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-Produktionsbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung. |
+| 2026-09-06 | Phase 7/13B: Erfolgreich fertig verarbeitete GPO-Backups werden in der Timeslot-Quellenzeile als `Ready` statt `Imported` bezeichnet. Die Aenderung betrifft ausschliesslich das Label des Endzustands `succeeded`; Queue-, Verarbeitungs-, Teil-, Fehler- und Recovery-Zustaende bleiben getrennt. Zehn fokussierte synthetische Tests und Client-Produktionsbuild erfolgreich; keine Daten-, API-, Persistenz- oder Schemaaenderung. |
+| 2026-09-06 | Phase 7: ASSESSOR-Branding auf eine gemeinsame transparente rote Marke umgestellt. Weisser Hintergrund, weisses A-Innenfeld und Haken sind echte transparente Aussparungen; Sidebar, Empty Workspace, Favicon und About verwenden dasselbe Asset. Der Brand-Trigger bleibt klickbar und zugaenglich beschriftet, besitzt aber keinen sichtbaren Hover-Buttonzustand. About zeigt das Logo mit 160 px prominent. Transparenz inhaltsfrei auf Alpha und fehlende deckende Weisspixel geprueft; fuenf fokussierte Tests sowie Client-/Serverbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung. |
+| 2026-09-06 | Phase 13B: GPO-Importduplikatfehler, veraltete Kontextpflicht und Upload-Snapshotzerlegung korrigiert. Observation-IDs aller Policy-Reducer binden neben Backupinstanz und Datei-Hash nun auch den exakten Quellartefaktpfad ein; byte-identische Dateien an unterschiedlichen GPO-Pfaden bleiben dadurch getrennte gueltige Beobachtungen. Reine GPO-Backups werden ohne zusaetzlichen OS-Scan automatisch gegen alle `eligible` importierten Microsoft-Baselines als getrennte Benchmarks ausgewertet; vorhandene DC-Kontexte bleiben Evidenz. Ein gemeinsam hochgeladener `selected-gpos`-Satz bleibt bei fehlenden oder gemischten Domainmetadaten ein einzelner partieller Snapshot. Parser-/Analyzervertrag auf 2.2.2, Snapshotaggregation auf 1.1.0 und Produktversion als kompatibler Patch auf 2.5.1 angehoben. Regressionen fuer identische Dateien, kontextfreien Auto-Vergleich, Baseline-Auswahl, gemischte Uploadmetadaten und 2.300-GPO-Lastfall gruen. Inhaltsfreie technische Kontrolle am betroffenen Import: HTTP 200, kein fehlgeschlagener Job, 184 erkannte GPOs und 3.638 Work-Ergebnisse (162 Uebereinstimmungen, 3.358 Abweichungen). Gesamtlauf 835 bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Keine SQL-Migration. |
+| 2026-09-06 | Phase 7: Echte ASSESSOR-Produktversion 2.5.0 eingefuehrt und von Processing-/GPO-Komponentenversionen getrennt. Der klickbare Markenblock oeffnet ein kompaktes About-Popup mit Buildzeit, Backend-Release, Importvertrag, GPO-Evaluation, Vergleich, Baselineanalyse, Snapshotaggregation, Policy-Identitaet und Credits fuer Michael Lukas und Binh Karl. Health meldet die Backend-Produktversion. 831 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung sowie Client-/Serverbuild erfolgreich. Keine Daten- oder Schemamigration. |
+| 2026-09-06 | Phase 13B: GPO-Benchmark auf die fachlich bestaetigte Microsoft-Sollwertsemantik begrenzt. Evaluator 1.3.3 waehlt nur zur beobachteten Umgebung passende Baselines, ignoriert leere Baselinezeilen und verhindert Pass/Fail bei nicht vergleichbaren Sollwerten. Security-Template-Registrywerte sind typbewusst vergleichbar. Nur Dummy neu ausgewertet: 363 Failed, 13 Passed, 8 Review/Warning und 0 Pass/Fail ohne Baselinewert. 831 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Keine anderen Mandanten oder Originaldaten veraendert. |
+| 2026-09-06 | Phase 13B: GPO-Baseline-Abweichungen als regulaere `Failed`-Zeilen in Work angebunden. Das eigene Blatt sowie Kategorie und Quelle heissen einheitlich `GPOs`; der normale Abweichungsfilter zeigt die Ergebnisse ohne Policy-Analyse-Zwischenschritt. Die Workspace-Ladung verwendet den aktuellen Evaluator und pro GPO-Backup den vollstaendigsten Baseline-Lauf, damit spaetere Teillaeufe keine vollstaendige Auswertung verdraengen. Den veralteten View-Hinweis im leeren Clientzustand entfernt. 825 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Serverbuild erfolgreich. Keine Daten- oder Persistenzmutation. |
+| 2026-09-06 | Phase 8/9/10: Das vereinbarte Quellen-Fortschreibungsmodell fuer unvollstaendige Folgetimeslots konkret geplant: drei Evidenzzustaende, getrennte Kennzahlen fuer gemessenen Fortschritt, Gesamtexposition und Evidence Coverage/Freshness, keine automatische Behebung oder Scoreverbesserung bei fehlender Quelle sowie auditierter Scope-Ausstieg. Zugleich die vollstaendige FindingReader-Bearbeitung an die bestehende Datenbank-Reviewgrenze angeschlossen. Stabile Occurrence-IDs verbinden Aggregate und Werkzeugblaetter; Bookmark, Status, Prioritaet, Owner/Team, Due Date, fuenf Freitextfelder und alle fuenf Marker werden optimistisch versioniert gespeichert. Vorhandene Browserreviews werden ohne Datenbankgegenstueck uebernommen, Datenbankreviews haben Vorrang. Additive JSONB-Erweiterung ohne SQL-Migration; 43 fokussierte synthetische Tests, 825 Standardtests, Local-only-/Designpruefung und Client-/Serverbuild erfolgreich; 8 optionale PostgreSQL-Tests uebersprungen. Keine realen Kundendaten gelesen oder veraendert. |
+| 2026-09-06 | Phase 13B auf den vom Nutzer bestaetigten Policy-Analyzer-Vergleich umgestellt: Evaluator 1.3.1 fuehrt je aktiver Baseline einen baseline-getriebenen Left Join gegen den importierten GPO-Istbestand aus. Gleich ist Passed, verschieden oder fehlend ist Abweichung, ohne Baselineempfehlung bleibt unbewertet; mehrere Baselines werden getrennt statt als Kontextmehrdeutigkeit behandelt. Konflikte und technisch unvergleichbare Werte bleiben Review, neutrale Vergleiche erzeugen keine Severity oder Findings. Migration 020 bindet jedes Ergebnis an genau eine Baselineanalyse und erlaubt fuer fehlende Ist-Werte eine NULL-Aggregationsreferenz. Work projiziert jeden Baselinevergleich als eigene Zeile mit kurzem Baseline-Namen; deduplizierte GPO-Reimporte koennen die aktuelle Baseline-Menge erneut auswerten. 821 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only, Designpruefung und Client-/Serverbuild erfolgreich. Vor der Dummy-Neuauswertung wurde ein Custom-Format-Backup erstellt. Ausschliesslich Dummy wurde neu ausgewertet: 3.638 Ergebnisse, 55 Passed, 3.556 Abweichungen, 27 Review; davon 3.483 explizit fehlende Ist-Werte. Keine anderen Mandanten ausgewertet. Phase 13B bleibt in Arbeit. |
+| 2026-09-06 | Phase 7/13B: In jeder Timeslot-GPO-Zeile steht nun eine eigene Delete-Aktion neben Evaluate beziehungsweise Retry. Der Warnungsdialog benennt den exakten GPO-Eintrag und garantiert den Erhalt des Timeslots und aller anderen Quellen. Der bestehende bestaetigungspflichtige DELETE-Endpunkt wurde von Dead Letter auf alle beendeten GPO-Importe erweitert; Queue/Running bleibt gesperrt. Local- und PostgreSQL-Persistenz entfernen atomar das Artefakt sowie direkt und transitiv abhaengige Processing-, Identity-, Snapshot-, Evaluation- und Finding-Derivate, waehrend die persistente Artefakt-Loesch-Outbox erhalten bleibt. Synthetische Regressionen pruefen erfolgreichen Import samt Snapshot und Reprocessing-Kette, Dead Letter, parallele Queue-Sperre, HTTP-Bestaetigung und Clientroute. 829 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Der GPO-Pfad benoetigt keine neue SQL-Migration und hat keine kanonischen Fachdaten mutiert. Beim anschliessenden Neustart wurde die bereits anstehende Migration 020 nach eindeutiger Benennung ihrer beiden CHECK-Constraints auf dem kanonischen 2.0-Bestand erfolgreich registriert; App und PostgreSQL-Backend liefern HTTP 200. Keine Realdaten gelesen und keine neue Datenbank erzeugt; Phase 7 bleibt abgeschlossen, Phase 13B in Arbeit. |
+| 2026-09-06 | Phase 7: Timeslot-Auswahl und Expansion wieder strikt getrennt. Ausschliesslich ein Klick auf die Checkbox markiert beziehungsweise demarkiert den Timeslot; Datum, freie Balkenflaeche, Zaehler und Dreieck gehoeren zur auf- und zuklappbaren Summary. Die bisherige Label-Klickflaeche um Datum und Checkbox wurde durch einen neutralen Container ersetzt, nur die Checkbox stoppt die Summary-Interaktion. 827 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
+| 2026-09-06 | Phase 7/13B: die vorhandene Fortschrittsanzeige als gemeinsame, nicht vorzeitig schliessbare Progress-Dialogkomponente fuer Scanimporte, Security-Baseline-Uploads, GPO-Ordner-/ZIP-Uploads sowie Profil-, Snapshot-, Baseline- und Finding-Berechnungen vereinheitlicht. GPO-Upload und Retry bleiben ueber die persistierte Job-ID bis zum Endzustand sichtbar statt bereits nach dem Queuing zu verschwinden; Texte sind bewusst auf einen kurzen aktuellen Arbeitsschritt begrenzt. 827 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only-, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine API-, Schema-, Persistenz- oder Datenmutation; Phase 7 bleibt abgeschlossen, Phase 13B in Arbeit. |
+| 2026-09-06 | Phase 13B: Baseline-Delete fuer Vollreimporte erweitert. Nach ausdruecklicher Bestaetigung werden referenzierende, reproduzierbare Policy-Evaluation-/Finding-Ketten entfernt; Kunden- und GPO-Quelldaten bleiben erhalten. Dialogtext verkuerzt. Fokussierte 20 Tests und Client-/Serverbuild erfolgreich. Vor dem Eingriff kanonisches PostgreSQL-Backup erstellt und lesbar geprueft; den letzten blockierten Baselineeintrag geloescht. Verifiziert: Katalog 0, Backend PostgreSQL gesund, App HTTP 200 und 51 GPO-Beobachtungen unveraendert vorhanden. |
+| 2026-09-06 | Phase 12/13B um die verbindliche Datenschutzgrenze der Result DB erweitert. PingCastle- und kuenftige Scanner-Zusatzinformationen werden nur ueber `result-db-supplemental-disclosure` 1.0.0 freigegeben: exakte Tool-/Property-Allowlist, enge Wertevalidatoren und kontrolliert neu aufgebaute Titel/Subject-Klassen; Identitaet, Originalwert, Attribute, Asset, Abschnitt, Locator und Quellzeitpunkt bleiben intern. Rohe GPO-Policy-Beobachtungen sind nur noch im expliziten `internal-analysis`-Modus fuer Work/Data-Hub-Auswertung verfuegbar, waehrend bestaetigte Policy-Findings in der Result DB bleiben. JSONL-Schema 1.1.0 erzwingt die Klassifikation und entfernt gesperrte Felder nochmals vor Serialisierung. 31 fokussierte Tests, alle 826 Standardtests, 8 erwartungsgemaess uebersprungene PostgreSQL-Tests, Local-only-/Designpruefung sowie Client-/Server-Produktionsbuild erfolgreich. Ausschliesslich synthetische Daten verwendet; keine Original-, Persistenz- oder Schemaaenderung. |
+| 2026-09-06 | Phase 13B/13C: automatische timeslotgebundene PingCastle-DC-Kontexte, GPMC-Core-/GPReport-Metadaten, begrenzter SAX-Parser, gemeinsame native Security-/Audit-Ziele, Import-Folgepipeline und Work-Bewertungsspalten implementiert. Migration 019 nach lesbar geprueftem Backup auf dem kanonischen Bestand angewandt; ausschliesslich Dummy neu verarbeitet: 51 Beobachtungen, 50 Review-Ergebnisse. 821 Tests bestanden, 8 optionale PostgreSQL-Tests uebersprungen; Local-only, Designpruefung und Client-/Serverbuild erfolgreich. Fehlendes Baselineoriginal und unzureichende Backupvollstaendigkeit bleiben dokumentierte Blocker; kein abgeschlossener Baseline-Abgleich und keine visuelle Browserabnahme behauptet. Temporaeren Dummy-QA-Test entfernt, Backup behalten. |
+| 2026-09-06 | Phase-7/12-Timeslotnavigation auf einen einzigen vertikalen Scrollcontainer vereinheitlicht: Die Quellenliste innerhalb eines ausgeklappten Timeslots besitzt keine eigene Maximalhoehe und keine eigene Scrollbar mehr. Ein Timeslot waechst mit allen Quellen und Aktionen; gescrollt wird ausschliesslich die gesamte aeussere Timeslot-Liste mit ihrem unteren Abstand. Die fokussierte Strukturregression trennt den erlaubten aeusseren `overflow-y`-Vertrag von der verbotenen inneren Scrollbegrenzung. Keine Daten-, API-, Persistenz- oder Fachlogikaenderung; Phase 7 und 12 bleiben abgeschlossen. |
+| 2026-09-06 | Phase-7/12-Timeslotnavigation nach Nutzerhinweis gegen eine optisch abgeschnittene letzte ausgeklappte Karte korrigiert: Der eigene scrollbare Timeslotlistenbereich behaelt seitlich und oben seine kompakte Geometrie, erhaelt unten jedoch den gemeinsamen 20-px-Abstand. Dadurch koennen Abschlusskontur und letzte Aktion vollstaendig ueber die Viewport-Unterkante gescrollt werden. Drei fokussierte Strukturtests, Designpruefung sowie Client-/Server-Produktionsbuild sind erfolgreich; keine Daten-, API-, Persistenz- oder Fachlogikaenderung. Phase 7 und 12 bleiben abgeschlossen. |
+| 2026-09-06 | Phase-11-Lokalbetrieb auf ausdruecklichen Nutzerwunsch konsolidiert: Der bekannte Datenstand `assessor-2_0` ist als einziger kanonischer lokaler ASSESSOR-PostgreSQL-Bestand festgelegt. `docker-compose.postgres.yml` verwendet dauerhaft den Compose-Projektnamen `assessor-2_0` und bindet `assessor-2_0_assessor-postgres-data` als vorhandenes externes Volume; `AGENTS.md` verbietet alternative ASSESSOR-Datenbanken und Fallbackports. Zwei fokussierte Konfigurationsregressionen, Compose-Validierung, Client-/Server-Produktionsbuild sowie HTTP-Health von Client und Backend sind erfolgreich. Der Gesamttest besitzt weiterhin genau den bereits dokumentierten unabhaengigen statischen Data-Hub-Open-Befund zur alten Quelltextformatierung. Keine Schema- oder Fachdatenaenderung; die separat bestaetigte Bereinigung der ASSESSOR-Container und -Volumes fuer 2.5, 2.4.1, 2.4 und den Phase-13-Testbestand betraf weder den kanonischen 2.0-Bestand noch fremde Docker-Anwendungen. Phase 11 bleibt abgeschlossen. |
+| 2026-09-04 | Phase-13B-GPO-Ordnerimport gegen einzelne nicht oeffenbare Windows-Verzeichniseintraege gehaertet: Direkter Picker und Fallback behandeln `getFile`-, Verzeichnisiterator- und Byte-Lesefehler pro Eintrag, behalten alle lesbaren Dateien und melden die Anzahl ausgelassener Eintraege ausdruecklich in der Erfolgsnachricht statt den gesamten Import mit der rohen Browser-NotFound-DOMException abzubrechen. Sind keine Dateien lesbar, bleibt der Import geschlossen. Metadaten- und Ressourcengrenzen gelten vor der Byteerfassung weiter. Eine neue synthetische Regression kombiniert lesbaren Inhalt, nicht oeffenbaren Handle und nicht lesbaren Dateikoerper; insgesamt 16 fokussierte UI-, Transport- und HTTP-Tests, Local-only-Sicherheitspruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Realdaten gelesen oder importiert und keine API-, Persistenz- oder Schemaaenderung; die UI macht eine moegliche Unvollstaendigkeit sichtbar, Phase 13B bleibt in Arbeit. |
+| 2026-09-04 | Phase-13B-GPO-Ordnerauswahl nach wiederholtem Windows-Dateireferenzfehler auf einen neuen Primaerpfad umgestellt: `Import GPO Folder` verwendet bei Verfuegbarkeit den explizit durch den Nutzer freigegebenen File-System-Access-Verzeichnispicker, traversiert ausschliesslich den gewaehlen Baum read-only und konstruiert stabile relative Pfade; der bisherige `webkitdirectory`-Selektor bleibt nur fuer Browser ohne diese API als Fallback bestehen. Beide Pfade laufen weiterhin durch denselben Metadaten-Preflight, die unmittelbare Byteerfassung, deterministische ZIP-Kompression und die unveraenderte projekt-/timeslotgebundene Submission. Eine neue synthetische Rekursionsregression sichert den direkten Verzeichnisvertrag; insgesamt 15 fokussierte UI-, Transport- und HTTP-Tests, Local-only-Sicherheitspruefung, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Realdaten gelesen oder importiert, keine allgemeinen Dateisystemrechte und keine API-, Persistenz- oder Schemaaenderung; Phase 13B bleibt in Arbeit. |
+| 2026-09-04 | Phase-13B-GPO-Verzeichnisupload nach erneuter Realfehler-Rueckmeldung auf sofortige Dateierfassung umgestellt: Alle Browser-Leseoperationen werden jetzt noch synchron im Auswahlereignis gestartet, bevor Windows einzelne spaeter sequenziell geoeffnete Verzeichnisreferenzen verlieren kann; die bereits erfassten Bytes werden anschliessend deterministisch komprimiert. Ein gemeinsamer plattformneutraler Metadaten-Preflight prueft Anzahl, Einzel- und Gesamtdatenmenge vor dem Start irgendeiner Leseoperation, sodass die sofortige Erfassung die bestehenden Ressourcengrenzen nicht umgeht. Drei neue synthetische Regressionen sichern gleichzeitigen Lesestart, begrenzte NotFound-Abbildung und Ablehnung vor dem Lesen; insgesamt 14 fokussierte UI-, Transport- und HTTP-Tests, Local-only-Sicherheitspruefung und Client-/Server-Produktionsbuild erfolgreich. Keine Realdaten gelesen oder importiert und keine API-, Persistenz- oder Schemaaenderung; Phase 13B bleibt in Arbeit. |
+| 2026-09-04 | Phase-13B-GPO-Dateiauswahl gegen waehrend der asynchronen Kompression verlorene Browser-Dateireferenzen gehaertet: Ordner- und ZIP-Input werden nicht mehr unmittelbar nach dem Change-Ereignis geleert, sondern erst nachdem Einlesen, Verpacken und Submission beendet sind. Der Ordnerpfad uebergibt zuvor eine stabile File-Liste; ein tatsaechlich nicht lokal verfuegbarer Eintrag liefert eine konkrete, inhaltsfreie Handlungsanweisung statt der rohen Browser-DOMException. Elf fokussierte UI-, Transport- und HTTP-Tests, Local-only-Sicherheitspruefung sowie Client-/Server-Produktionsbuild erfolgreich. Keine Realdaten gelesen oder importiert und keine API-, Persistenz- oder Schemaaenderung; Phase 13B bleibt in Arbeit. |
+| 2026-09-04 | Phase-13B-GPO-Ordnertransport an die vorhandenen sicheren Archivgrenzen angeglichen: Der Browser erzeugt fuer einen ausgewaehlten Backupordner nun ein deterministisches ZIP mit verlustfreier Deflate-Kompression pro Datei und behaelt unveraendert CRC-, Pfadnormalisierungs-, Kollisions-, Eintrags-, Einzeldatei- und Transportpruefungen. Dadurch darf der gepruefte Ordnerinhalt bis zur bereits serverseitig geltenden Grenze von 512 MiB reichen, waehrend die tatsaechlich uebertragene ZIP-Datei weiterhin auf 100 MiB begrenzt bleibt; nicht komprimierbare Inhalte koennen diese Transportgrenze weiterhin nicht umgehen. Eine synthetische Byte-fuer-Byte-Regression belegt, dass Quellinhalt oberhalb einer kleineren Transportgrenze komprimiert, serverseitig verifiziert und identisch wiederhergestellt wird. Neun fokussierte GPO-Transport-/HTTP-Tests, Local-only-Sicherheitspruefung, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Im Gesamtlauf bestanden 791 Tests; eine unabhaengige statische Data-Hub-Open-Pruefung erwartet weiterhin die alte einzeilige Quelltextformatierung der funktional vorhandenen Dashboard-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Realdaten gelesen oder importiert und keine API-, Persistenz- oder Schemaaenderung; Phase 13B bleibt in Arbeit. |
+| 2026-09-04 | Phase-7/13B-Work-Quellenfilter nach der additiven GPO-Projektion korrigiert: Die projektweite Facette `Source: Scan` bleibt innerhalb der auf zehn sichtbare Filter begrenzten Leiste verbindlich als letzter sekundaerer Filter erhalten und kann dadurch nicht mehr von den zusaetzlichen GPO-Feldern verdraengt werden. Bestehende Scannerblaetter und Werkzeugwerte bleiben unveraendert; `Group Policy` wird nur als weitere Quelle und als eigenes Beobachtungsblatt ergaenzt. Zwei neue synthetische Regressionen sichern vier Scannerwerkzeuge plus GPO sowie die Filtergrenze ab. 15 fokussierte Tests, Local-only-Sicherheitspruefung, Designpruefung und Client-/Server-Produktionsbuild erfolgreich. Im Gesamtlauf bestanden 790 Tests; eine unabhaengige statische Data-Hub-Open-Pruefung erwartet weiterhin die alte einzeilige Quelltextformatierung der funktional vorhandenen Dashboard-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Realinhalte gelesen und keine Daten-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen und Phase 13B in Arbeit. |
| 2026-09-03 | Phase-7-Client-Info-Standardansicht nach Nutzerreferenz festgelegt: `Assessment Status` startet als einzige geoeffnete Informationskarte; Directory Coverage, Certificates & PKI, Infrastructure Details, Identity & Privilege, GPO & Password Hygiene, Control Paths & Trusts, Infrastructure & Resilience, Severity Distribution und Directory Overview starten minimiert und vollbreit. Alle Karten bleiben ueber die gemeinsamen Dreiecke individuell schaltbar. 15 fokussierte Dashboard-/Interaktions-/Dreieckstests und Client-/Server-Produktionsbuild erfolgreich. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Client-Info-Detailkorrektur umgesetzt: minimierte Informationskarten behalten mit voller Spaltenbreite dieselbe Breite wie im maximierten Zustand; Collapse reduziert nur die Hoehe. Der PingCastle-Engine-Hinweis wurde aus `Directory Overview` entfernt, ohne die normalisierte Quellprovenienz zu veraendern. 13 fokussierte Dashboard-/Interaktionstests und Client-/Server-Produktionsbuild erfolgreich. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
| 2026-09-03 | Phase-7-Client-Info auf stabile Spalten und eine geschlossene Kopfzone korrigiert. Das laufzeitgemessene dichte Masonry wurde durch drei feste, semantisch zugeordnete Kartenstapel mit 3/2/2 Karten ersetzt; minimierte und maximierte Karten bleiben dadurch immer in ihrer Spalte und nur nachfolgende Karten derselben Spalte ruecken auf. Die sechs KPI-Kacheln fuellen auf Desktop gemeinsam die Hoehe von `Assessment Status`, sind groesser typografiert und folgen nun Compliance Score, Deviation, High Severity, Passed, Typed Observations, Directory Sections. Compliance ist als H1 hervorgehoben; ausschliesslich Deviation und High Severity sind klickbar. 15 fokussierte Dashboard-/Interaktions-/Dreieckstests, Client-/Server-Produktionsbuild, Local-only- und Designpruefung erfolgreich. Im Gesamtlauf bestanden 780 Tests; eine unabhaengige statische Data-Hub-Open-Pruefung erwartet noch die alte einzeilige Quelltextdarstellung der weiterhin korrekt vorhandenen `dashboard`-Navigation, 8 optionale PostgreSQL-Tests wurden uebersprungen. Keine Realinhalte gelesen und keine Daten-, Import-, API-, Persistenz- oder Schemaaenderung; Phase 7 bleibt abgeschlossen. |
diff --git a/docs/RESULT_CONTRACT.md b/docs/RESULT_CONTRACT.md
index 48ff6c3..4ebb8c3 100644
--- a/docs/RESULT_CONTRACT.md
+++ b/docs/RESULT_CONTRACT.md
@@ -104,7 +104,7 @@ Jede Ableitung trägt `ioe_rule_id`, `ioe_rule_version`, `ioe_derivation_method`
| CIS-CAT | XCCDF informational | compliance_check | xccdf_result = informational | informational | false |
| GPO vs. Baseline | Abweichung | policy_deviation | verdict = deviation | fail | false |
| GPO vs. Baseline | Uebereinstimmung | policy_deviation | verdict = match | pass | false |
-| GPO vs. Baseline | Setting fehlt beim Subjekt | policy_deviation | verdict = missing_on_subject | fail | false |
+| GPO vs. Baseline | Setting fehlt beim Subjekt | policy_deviation | verdict = missing_on_subject | informational | false |
| GPO vs. Baseline | Setting nur beim Subjekt | policy_deviation | verdict = extra_on_subject | warning | false |
| GPO vs. Baseline | nicht vergleichbar | policy_deviation | verdict = not_comparable | unknown | false |
@@ -404,9 +404,37 @@ Vertrags wird bei Bedarf daraus abgeleitet, nicht umgekehrt gespeichert.
`ioe_derivation_method` sowie `exposure_state` sind additive Spalten auf der
bestehenden Occurrence-Tabelle (`assessor_finding_occurrences`,
Migration `008_result_contract_facets.sql`), nicht Spalten einer neuen
-Haupttabelle. `result_compliance` und `result_deviation` als eigene Blöcke
-wurden nicht angelegt, da für beide noch kein Producer existiert
-(CIS-CAT-Formatentscheidung offen, GPO-/Baseline-Submodell deferiert).
+Haupttabelle. `result_compliance` und `result_deviation` wurden nicht als neue
+Haupttabellen angelegt. GPO-/Baseline-Vergleiche stammen aus den versionierten
+Policy-Evaluation-Entitäten und werden nur im Read-Modell vereinheitlicht.
+
+### Datenschutzgrenze der Result DB
+
+Die Result DB ist kein Rohdaten- oder Kundenkontextspeicher. Kanonische Findings
+bleiben mit ihren allgemeinen Regeltexten, Bewertungen und Frameworkreferenzen
+sichtbar; verknuepfte Results, originale Tabellenfelder und vollstaendige
+Scannerkontexte bleiben ausserhalb dieser Projektion erhalten.
+
+Ergaenzende Scannerbeobachtungen durchlaufen vor der Unified-Result-Projektion
+die versionierte, fail-closed Disclosure Policy
+`result-db-supplemental-disclosure` 1.0.0. Eine Beobachtung wird nur ausgegeben,
+wenn Werkzeug, Property und ein enger Datentyp-/Wertebereich ausdruecklich
+freigegeben sind. Titel, Subject-Klasse und Property werden aus der kontrollierten
+Regel neu aufgebaut. Subject-Identitaet, Originalwert, Attribute, betroffener
+Assetname, Abschnitt und Source Locator werden niemals aus der Beobachtung in
+die Result DB uebernommen. Unbekannte Werkzeuge und neue Zusatzfelder bleiben
+vollstaendig in der internen Persistenz, sind aber bis zu einer bewussten
+Klassifikation nicht Teil der Result DB. Das betrifft nicht ihre regulaeren
+kanonischen Findings.
+
+Rohe GPO-Policy-Beobachtungen sind ebenfalls kein Result-DB-Inhalt. Sie bleiben
+im expliziten `internal-analysis`-Lesemodus fuer Work und GPO Analysis erhalten;
+versioniert evaluierte Soll-/Ist-Vergleiche erreichen die normale Result DB als
+`policy_deviation`. Ohne freigegebene Risikoregel bleibt die Severity `unknown`;
+die Finding Factory darf nur belegte Ergebnisse anreichern und erzeugt keine
+doppelte Result-Zeile. Der JSONL-Export verwendet Schema 1.1.0, verlangt fuer jede
+Environment-Zeile eine Disclosure-Klassifikation und entfernt die gesperrten
+Felder nochmals unmittelbar vor der Serialisierung.
### Asset-/Kantenschicht: Struktur ohne Producer
diff --git a/docs/UNIFIED_RESULT_MODEL.md b/docs/UNIFIED_RESULT_MODEL.md
index b27b56c..5a166ae 100644
--- a/docs/UNIFIED_RESULT_MODEL.md
+++ b/docs/UNIFIED_RESULT_MODEL.md
@@ -7,7 +7,7 @@ Status: Policy-Finding- und Read-Vertikalschnitt umgesetzt; Gesamtmodell in Arbe
## Zweck
Das gemeinsame Result-Read-Model stellt Scanner-Finding-Vorkommen und
-nachvollziehbar erzeugte bestätigte Policy-Abweichungen über eine einheitliche,
+nachvollziehbar erzeugte Policy-Baseline-Vergleiche über eine einheitliche,
nicht schreibbare Abfragegrenze bereit. Es ersetzt weder das kanonische
Finding-Modell noch die GPO-, Baseline- oder Evaluationsentitäten.
@@ -24,7 +24,7 @@ Finding-Modell noch die GPO-, Baseline- oder Evaluationsentitäten.
| Scannerpipeline | erfüllt | Formatadapter, Source Extractor, Candidate-Mapping und kanonische Persistenz sind getrennt | keine werkzeugspezifische Resultpipeline ergänzen |
| GPO-Ingestion | teilweise | technische Identität, Baselineanalyse, Snapshotaggregation, Evaluation und Finding Factory sind vorhanden | freigegebene Inbox-ADMX-/Regelkataloge und UI fehlen |
| PostgreSQL | erfüllt für den Read-Pfad | Migrationen 001–017 persistieren Scanner-, Policy-Evaluation- und Policy-Finding-Provenienz | vollständig SQL-seitige Facetten bleiben optional |
-| Repository/API | erfüllt | gemeinsame Result-, Facetten-, Detail- und Kategorienqueries lesen Scanner- und bestätigte Policy-Findings in Local, PostgreSQL, HTTP und Client | UI-Anbindung bleibt offen |
+| Repository/API | erfüllt | gemeinsame Result-, Facetten-, Detail- und Kategorienqueries lesen Scanner-Findings, neutrale Policy-Vergleiche und angereicherte Policy-Findings in Local, PostgreSQL, HTTP und Client | UI-Anbindung bleibt offen |
| UI-Filter | teilweise | generische dynamische Dataset-Facetten sind vorhanden | serverseitige gemeinsame Resultfacetten sind noch nicht angebunden |
Gefährliche Doppelimplementierungen wären insbesondere eine zweite Scanner-
@@ -74,13 +74,19 @@ Quelle -> Formatadapter -> DecodedSourceDocument -> Source Extractor
```text
GPO-Backup -> GPOBackupInstance -> PolicyObservation -> PolicyIdentity
-> EvaluationRun -> PolicyEvaluationResult
- -> Policy Finding Factory -> Policy Finding Occurrence
-> Unified Result Projection
+ -> optional: Policy Finding Factory -> angereicherte Projektion
```
-Die Policyseite projiziert ausschließlich vollständig belegte, bereits als
-`eligible` bestätigte konfigurierte Abweichungen. Review- und Lückenfälle
-bleiben außerhalb der Finding-Projektion.
+Die Evaluation vergleicht eine technisch eindeutig aufgelöste Kundeneinstellung
+neutral direkt mit dem Wert der importierten, eindeutig passenden Baseline. Fehlt
+eine zusätzliche Katalogregel vollständig, ist ein typgetreuer Equality-Vergleich
+zulässig; er erzeugt Matches oder konfigurierte technische Abweichungen, aber
+keine Severity und keine Finding-Freigabe. Jeder deterministische Vergleich wird
+direkt als `policy_deviation` unter dem Source Tool `GPOs` projiziert. Die
+Policy-Finding-Projektion ersetzt die neutrale Zeile nur bei vollständig belegten,
+durch eine freigegebene Risikoregel als `eligible` bestätigten Abweichungen und
+ergänzt dann Severity sowie Risikokontext.
## Statusdimensionen
@@ -120,8 +126,10 @@ Die API stellt Results, Facetten, Kategorien und Details unter `/api/v1/results`
- Die PostgreSQL-Read-Projektion leitet Kategorien derzeit weiterhin aus den
versionierten Domainobjekten ab; die relationale Struktur ist für den
folgenden vollständig SQL-seitigen Filterpfad vorbereitet.
-- Der produktive Policy-Regelkatalog ist bis zur fachlichen Kuratierung leer;
- deshalb entstehen aus dem realen Bestand weiterhin keine Policy-Findings.
+- Der produktive Policy-Regelkatalog ist bis zur fachlichen Kuratierung leer.
+ Neutrale Baseline-/GPO-Vergleiche funktionieren ohne ihn; Policy-Findings,
+ Severity, stärker/schwächer und Abhängigkeitsauswertung entstehen weiterhin
+ erst nach fachlicher Freigabe entsprechender Regeln.
- Konflikte, Katalog-/Parserlücken, partielle Analysen und unaufgelöste
Identitäten benötigen noch eine gemeinsame UI-Darstellung.
- Lebenszykluswerte aus Vergleichen werden im ersten Schnitt nicht erfunden.
diff --git a/docs/architecture/gpo-threat-model.md b/docs/architecture/gpo-threat-model.md
index b5dbd21..0a7e149 100644
--- a/docs/architecture/gpo-threat-model.md
+++ b/docs/architecture/gpo-threat-model.md
@@ -1,8 +1,17 @@
# GPO-/Baselineanalyse – Bedrohungsmodell und Speichergrenze
-Stand: 2026-08-04
+Stand: 2026-09-06
+
+## Tooluebergreifende AI search (Phase 7, 2026-09-06)
+
+Die ausdrueckliche Nutzerfreigabe erweitert die Suche auf alle FindingReader-Tools. Der lokale, quellenbelegte Public-Identifier-Katalog ergaenzt die bisherigen GPO-Begriffe um exakte Registryziele, Windows-Rechte, ASR- und Scanner-Regelkennungen. Exportiert wird ausschliesslich die katalogeigene Schreibweise oder festes Fachvokabular; kein ungepruefter Berichtstext. Eng begrenzte numerische/boolesche Baselineziele werden nur fuer erkannte Einstellungen und als ausgewaehlter, nicht unabhaengig verifizierter Benchmarkwert weitergegeben. Kundenseitige Istwerte, Konten/SIDs, Namen, Quellpfade, freie Beschreibungen/Abhilfe und importierte URLs bleiben ausgeschlossen. Unbekannte Regeln bleiben als Topic-Suche gekennzeichnet. Keine automatische Anfrage oder Uebernahme von AI-Antworten in Bewertungen. Dies praezisiert/erweitert die historischen Freigaben unten; Details, Grenzen und Katalogpflege siehe `public-ai-search.md`. Google-Verbindungs-/Kontodatenverarbeitung und betriebliche Freigaben bleiben unveraendert relevant.
+
Phase: 13B, verifiziert bis zum Registry.pol-Parser sowie zur Job- und Ergebnispersistenz
+## AppLocker-Wertdarstellung (Phase 7, 2026-09-06)
+
+Die reine Leseprojektion formatiert AppLocker-XML mit dem vorhandenen SAX-Parser als escapeten Text. Grenzen: 262.144 Zeichen, 2.000 Elemente, 32 Ebenen, 128 Attribute je Element. DTD, Processing Instructions, fremde Namespaces und fehlerhaftes XML werden nicht strukturiert dargestellt; der unveraenderte Wert bleibt inerte Textausgabe. Bedingungen, Ausnahmen und unbekannte Erweiterungen bleiben getrennt erhalten. Keine aktive HTML-Darstellung, externen Referenzabrufe, Bewertungsaenderung oder Mutation der Originaldaten.
+
## Schutzgüter
- Vertraulichkeit unveränderter GPO- und Baselineoriginale
@@ -13,6 +22,14 @@ Phase: 13B, verifiziert bis zum Registry.pol-Parser sowie zur Job- und Ergebnisp
## Vertrauensgrenzen
+Conflict-Results-Leseprojektion (2026-09-06): Aus vorhandenen normalisierten Beobachtungen abgeleitete Konfliktvarianten und Quellreferenzen werden im bestehenden Results-Fenster ausschliesslich als escapete Tabellenzellen/Praeambel dargestellt, niemals als HTML, Markdown-Links oder aktive Pfade. Der interne JSON-Umschlag wird vor Darstellung auf Version, Form, zwei Tabellen, maximal acht Spalten/20.000 Zeilen je Tabelle und 10 MiB Text begrenzt; bei Fehlern bleibt die urspruengliche Evidenzansicht bestehen. Whitespace wird im Umschlag escapet, damit die generische Tabellenprojektion signifikante Wertunterschiede nicht verwischt. Keine neue externe Navigation, Uebermittlung, Datenbankmutation oder Vergleichsentscheidung.
+
+Erweiterung AI-Suchkontext (2026-09-06, Phase 7): Auf ausdruecklichen Nutzerwunsch werden Scope (computer/user), exakt freigegebene oeffentliche Baselinebezeichnungen und feste Vergleichslabels als anonymes Backup-Pruefszenario uebermittelt. Diese Freigabe ersetzt die vorherige vollstaendige Auslassung dieser Kontextfelder. Audit-Abhilfe fuer bekannte Microsoft-Subkategorien System Integrity/Logoff wird nur aus einer vollstaendig passenden, begrenzten Grammatik mit zwei eindeutigen booleschen Sollflags und passendem Titel/Scope neu aufgebaut; Expected und Must include bleiben getrennt. Unbekannte IDs, Zusatztexte, mehrdeutige Felder und andere freie Abhilfetexte werden verworfen. Description-Platzhalter sowie nicht unabhaengig verifizierte importierte Beschreibungen bleiben ausgeschlossen. Keine automatische Uebermittlung, keine Kundennamen/Istwerte/Quellpfade und keine Live-Suche mit Test- oder Kundendaten. Oeffentliche Fachbegriffe allein sind keine Zusicherung von DSGVO-Konformitaet: Google verarbeitet weiterhin Verbindungs-/IP- und gegebenenfalls Kontodaten; betriebliche Freigaben bleiben erforderlich. Historische Schutzentscheidungen gelten ausserhalb dieser engen Nutzerfreigabe unveraendert.
+
+Praezisierung AI search (2026-09-06): Auf ausdruecklichen Nutzerwunsch ersetzt ein Google-AI-Mode-Browserlink (`search?udm=50&q=...`) die klassische Suchnavigation. Der Prompt verlangt offizielle Microsoft-Quellen, genaue Konfigurationshinweise und versionsabhaengige Baselineempfehlungen; dies ist eine Anfrage an Google, keine Garantie ueber die Antwortqualitaet oder Quellenauswahl. Eine feste Liste oeffentlicher Firewall-Einstellungsnamen, Domain-/Private-/Public-Profilbezeichnungen und Microsoft-Produktversionen ergaenzt die bestehenden freigegebenen Begriffe. Nur exakte Einstellungsnamen werden uebernommen, indem auf die fest hinterlegte oeffentliche Schreibweise abgebildet wird; rohe Metadaten bleiben lokal. Unbekannte Namen fallen auf das Fachthema zurueck. Keine Aenderung an Opener-/Referrerschutz oder Klickpflicht; keine API-/Aboanbindung, keine automatische Pruefung privater Google-Kontodaten. Google kann AI Mode je nach Konto/Region sperren oder den Deep Link aendern; Suchantworten werden nicht in Assessor-Bewertungen uebernommen.
+
+Nutzerfreigegebene Websuche (2026-09-06): Der GPO-FindingReader darf ausschliesslich nach einem bewussten Klick eine HTTPS-Suche bei Google mit `site:learn.microsoft.com` oeffnen. Die Query wird nur aus fest im Quellcode freigegebenem oeffentlichem Microsoft-Vokabular aufgebaut. Importierte Finding-/GPO-/Kunden-/Baseline-Namen, Ist-/Sollwerte, Registry-/Datei-/Netzwerkpfade, Beschreibungen, URLs und Identitaeten werden niemals in die Query kopiert. Fuer exakt bekannte oeffentliche Einstellungsnamen existiert eine kleine feste Zuordnung; ansonsten wird ein allgemeines Fachthema gesucht. `noopener`, `noreferrer` und `referrerPolicy=no-referrer` verhindern Opener-/Referrerweitergabe. Keine automatische Anfrage, Telemetrie, Vorabpruefung, Such-API oder Uebertragung von Uploads. Der Suchanbieter erhaelt technisch weiterhin die Browserverbindung/IP und ggf. seine eigenen Cookies; keine Zusage anonymer Nutzung. ADML-Beschreibungen und abgeleitete Abhilfe werden nur als escapeter Text gerendert, nicht als HTML oder ausfuehrbare Links. Diese ausdrueckliche Freigabe erweitert nicht die uebrigen lokalen Verarbeitungsgrenzen.
+
Alle Uploadbytes, Dateinamen, Browser-Relativpfade, Archivpfade, XML-Inhalte, Backupmetadaten, Zeitstempel und Herstellerpakete sind nicht vertrauenswürdig. Der Browser, Dateiendungen und Client-MIME sind keine Autorität. Das Backend validiert Bytes, Hash, Pfade, Größen, Beziehungen und Benutzerentscheidungen erneut. PostgreSQL speichert Fachzustand; Originalbytes liegen getrennt außerhalb des Webroots hinter einer backendkontrollierten Speicher-ID.
Ein Parserworker begrenzt Zeit und Speicher, isoliert aber keinen bösartigen nativen Code. Importierte Programme, Skripte, Bibliotheken und Makros werden niemals geladen oder ausgeführt. Ein später optionaler externer Adapter benötigt einen administrativ freigegebenen festen Pfad und Hash, einen niedrig privilegierten Prozess ohne Shell und Netzwerk sowie harte Zeit-, Umgebungs- und Ausgabegrenzen.
@@ -59,6 +76,9 @@ Ein unsicherer Pfad, eine Kollision, ein Link, eine Grenzverletzung, ein Hashfeh
## Verifizierte technische Kontrollen
+- Nachtrag 2026-09-06: Metadaten-XML verwendet einen SAX-Parser ohne DOM, mit maximal 64 MiB je Datei, 500.000 Elementen, Tiefe 128 und begrenztem Identitaetsfeldpuffer. Das gemeinsame selektive Entpackbudget betraegt hoechstens 128 MiB; globale ZIP-, Datei-, Workerzeit- und Heapgrenzen bleiben erhalten. Die fruehere Anforderung an ein schliessbares Metadaten-JSDOM entfaellt; Preference-DOMs bleiben unveraendert. Synthetischer Lasttest: 2300 GPOs ueber ZIP und Ordnertransport, einschliesslich einer Metadatendatei groesser als 2 MiB.
+- Nachtrag 2026-09-06: Baselinepakete lesen auch Security-Template- und Advanced-Audit-Artefakte durch dieselben begrenzten Parser/Reducer wie Kundenbackups. Native Abschnitt-/Schluesselidentitaeten ersetzen keine Registry- oder Targetingsemantik. Automatische Profilableitung bleibt auf gespeicherte Beobachtungen desselben Assessments begrenzt; unbekannte Plattformen und mehrere Snapshotgruppen erzeugen keine erfundene Freigabe. Bestehende Vollstaendigkeits-, Konflikt-, Risiko- und Finding-Grenzen gelten unveraendert.
+
- Der persistente GPO-Statusendpunkt prüft den Mandanten und gibt je GPO-Artefakt nur technischen Dateinamen, Größe, Queue-/Processingzustand, Versuche, Zeitpunkte, Fehlercode und Backupinstanzzahl aus. Die Mandantenansicht lädt diese Werte neu und pollt nur solange sie sichtbar ist; Speicherschlüssel und Rohinhalte werden nicht ausgegeben.
- Die Artefakt-/Jobanlage ist in lokaler und PostgreSQL-Persistenz atomar. PostgreSQL-Rollback, unmittelbares Entfernen einer neuen Dateikopie bei Commitfehler, idempotente Reparatur eines Legacy-Artefakts ohne Job sowie alters- und mengenbegrenztes Entfernen eines synthetischen unreferenzierten Objekts sind verifiziert. Reconciliation startet mit dem Backend und läuft standardmäßig stündlich; unbekannte Namen, Links und junge Objekte werden nicht gelöscht; bei leerem vertrauenswürdigem Referenzbestand findet überhaupt keine Objektlöschung statt.
diff --git a/docs/architecture/policy-analyzer-comparison-contract.md b/docs/architecture/policy-analyzer-comparison-contract.md
new file mode 100644
index 0000000..c73a13c
--- /dev/null
+++ b/docs/architecture/policy-analyzer-comparison-contract.md
@@ -0,0 +1,42 @@
+# GPO comparison contract
+
+## Microsoft evidence reviewed on 2026-09-06
+
+- [Microsoft Security Compliance Toolkit](https://www.microsoft.com/en-us/download/details.aspx?id=55319): official PolicyAnalyzer.zip, bundled **Policy Analyzer.pdf**, version 4.0, pages 1 and 6. Read directly from the official ZIP in memory; no executables run.
+- [Policy Analyzer introduction](https://techcommunity.microsoft.com/blog/microsoft-security-baselines/new-tool-policy-analyzer/701049).
+- [ControlPolicyConflict / MDMWinsOverGP](https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-controlpolicyconflict).
+- [Windows Hello for Business policy conflicts](https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/configure#policy-conflicts-from-multiple-policy-sources).
+
+Policy Analyzer distinguishes differing configured values from absent settings. Repeated definitions of the same setting are indicated separately. The comparison retains registry data types: a numeric 5 and a text "5" differ. It can compare policy sets and local effective state; the latter is a separate operation.
+
+## User-facing outcomes
+
+| Outcome | Evidence required |
+| --- | --- |
+| Fail / Misconfigured | Explicit nonempty Microsoft recommendation, an actual configured customer value and a persisted deterministic mismatch. |
+| Not configured | Explicit nonempty Microsoft recommendation and a missing customer setting; informational, excluded from Fail and Deviation. |
+| Pass | Explicit Microsoft recommendation and a persisted deterministic match with an actual customer value. |
+| Conflicts | Multiple distinct typed customer values for the same setting, or explicitly recorded contradictory recommendations within one baseline set. |
+| Duplicates | Multiple source entries configuring the same setting to the same typed value. |
+
+Registry addresses include computer/user scope (implicit HKLM/HKCU in Registry.pol), key and value name. Address matching ignores case; value data retains case and type. Different value names under the same key are distinct settings. Native security-template and advanced-audit settings use their resolved identities. Assessments and projects are never merged for collision detection.
+
+Microsoft also calls configured differences *between* policy sets conflicts. ASSESSOR labels configured customer-versus-benchmark mismatches Fail. The user's 2026-09-06 correction replaces the earlier four-outcome contract: missing settings remain a separate informational outcome. GPO Deviation includes only Misconfigured, not Conflicts, Duplicates, missing values or review-only records. Other scanner deviation semantics remain unchanged. A conflict in the imported set is not a claim that both settings apply to the same endpoint: GPO backup analysis does not establish resultant policy.
+
+One baseline comparison creates one Work row with all source references. One customer collision group creates one Conflicts/Duplicates row. A duplicate group may also have a separate Pass/Fail benchmark result; these are different questions. Multiple benchmarks do not themselves create duplicate customer settings.
+
+Unsupported, unbound, not-evaluated, and ordinary review-only observations do not create Work rows. Diagnostics and original evidence remain available separately. Existing persisted data is not deleted or reclassified by this presentation change.
+
+## Hybrid AD / Intune
+
+A GPO and an Intune policy can prescribe conflicting values for an equivalent setting. This requires both policy sources, device/user assignments, an explicit CSP-to-GPO mapping, and applicable precedence rules. Matching raw registry strings is insufficient because equivalent GPO and CSP settings may use different locations.
+
+MDMWinsOverGP is device-scoped, defaults to 0, and governs Policy CSP equivalents only. It is not a universal MDM priority rule. Microsoft documents separate behavior for PassportForWork/Windows Hello for Business, where mixed GPO/CSP configuration can prevent CSP settings from applying. MDM diagnostics can report GP settings blocked by an MDM equivalent.
+
+The current importer does not provide Intune policy settings and assignment evidence. Hybrid status from another report alone cannot establish such a conflict. Hybrid conflict evaluation therefore remains an explicit future input/mapping task; no synthetic Intune conflict is inferred from GPO backups.
+
+## Verification and remaining parity work
+
+Synthetic regression coverage includes absent/empty baselines, missing customer values, typed collisions, address case, different value names, scope and timeslot isolation, baseline separation, duplicate read rows, source preservation, and a 2300-GPO group. Work and the analysis summary use the same builder.
+
+This is not a claim of complete executable parity with Policy Analyzer. A differential run of the same synthetic packages through Policy Analyzer and ASSESSOR remains required, including cross-format Registry.pol/security-template equivalence, ordered delete instructions, supported type families and translated identifiers. Conditional Group Policy Preferences and resultant endpoint policy require additional semantics/evidence and stay excluded from automatic claims.
diff --git a/docs/architecture/public-ai-search.md b/docs/architecture/public-ai-search.md
new file mode 100644
index 0000000..96dcefa
--- /dev/null
+++ b/docs/architecture/public-ai-search.md
@@ -0,0 +1,25 @@
+# Public AI search
+
+Presentation-only, Phase 7. The shared FindingReader exposes AI search for every tool, including mixed-tool workspaces. An explicit click opens Google AI Mode with opener/referrer protection. No background lookup, runtime catalog download, automatic AI evaluation or report upload is introduced.
+
+## Public evidence boundary
+
+`src/profiles/public-search/catalog.json` is a public-identifier snapshot reviewed on 2026-09-06: 67 registry targets, 45 privilege constants, 19 ASR identifiers, 161 Maester IDs and 51 PingCastle IDs. Source URLs accompany the identifiers. It is not a complete or automatically updated vendor catalog. It contains identifiers, not copied vendor descriptions or customer report prose. Noncanonical source notations (query-style value names or ambiguous path separators) are excluded rather than guessed.
+
+- Registry matches require the complete canonical key plus value name; only the catalog-owned spelling is exported. Private extensions do not match.
+- Native sections and keys resolve to public security-policy identities. ASR identifiers also require the Defender ASR registry family.
+- Scanner IDs must exist in the tool-specific snapshot. Dynamic instance suffixes are discarded.
+- CIS-CAT, Purple Knight, generic and unresolved rules use locally recognized fixed technical concepts. Only fixed vocabulary is sent, not the input excerpt. Registry lookup is tool-independent.
+- Public product families and exact scope/status enums add context without proving OS/role applicability. Existing exact GPO baseline/audit context remains available.
+- An identified numeric/boolean setting may include a bounded selected benchmark target (integer 0–65535 or boolean). It is labeled as selected, not independently verified as a Microsoft recommendation. Assigned accounts, SID lists, strings, arbitrary JSON and all customer actual values are excluded.
+- Imported descriptions, remediation, locators, identities, URLs, owner information and free-form titles are never passed through. Imported ADML provenance alone does not establish that arbitrary prose is public.
+
+The search requests the exact control, purpose, risk, configuration steps, verification and direct primary-source links, in German. Azure registry identity references do not replace the selected SCT benchmark or determine its expected value. AI output never changes findings or grading.
+
+## Incomplete evidence and maintenance
+
+The link exposes its specificity (`setting`, `rule`, `topic`) and full query in its tooltip. Unresolved cases explicitly request topic discussion rather than an invented rule or recommendation. No promise of complete coverage, vendor-verbatim guidance, anonymity or GDPR compliance is made. Google handles connection/IP and potentially account/cookie data; organizational approval remains necessary.
+
+Extend the catalog only from independently reviewed public publisher sources, with attribution and synthetic tests. Never learn public vocabulary automatically from customer reports. Tests cover all tool links, mixed workspaces, private suffixes, complete path matching, numeric bounds, ambiguous fields and catalog integrity. Tests do not query Google or inspect real tenant content.
+
+GPO badges use existing section/type and registry family evidence. System Access, Privilege Rights, Registry Values and related sections are display categories, not new outcomes. Registry/Software/System are structural fallbacks; specific product/security families take precedence. Description text does not assign badges.
diff --git a/index.html b/index.html
index edbeb87..72f8ff7 100644
--- a/index.html
+++ b/index.html
@@ -7,7 +7,7 @@
http-equiv="Content-Security-Policy"
content="__ASSESSOR_CSP__"
/>
-
+
ASSESSOR
diff --git a/package-lock.json b/package-lock.json
index e330a41..b65bbc3 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -1,12 +1,12 @@
{
"name": "assessor",
- "version": "0.1.0",
+ "version": "2.5.5",
"lockfileVersion": 3,
"requires": true,
"packages": {
"": {
"name": "assessor",
- "version": "0.1.0",
+ "version": "2.5.5",
"dependencies": {
"@fontsource-variable/inter": "^5.3.0",
"jsdom": "^29.1.1",
diff --git a/package.json b/package.json
index 17f90ee..636fb05 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
{
"name": "assessor",
- "version": "0.1.0",
+ "version": "2.5.5",
"private": true,
"type": "module",
"scripts": {
diff --git a/server/assessor-http-server.ts b/server/assessor-http-server.ts
index 27e17df..efa2f62 100644
--- a/server/assessor-http-server.ts
+++ b/server/assessor-http-server.ts
@@ -27,11 +27,13 @@ import type { GpoPolicyFindingService } from './gpo/gpo-policy-finding-service';
import type { GpoPolicyAnalysisOverviewService } from './gpo/gpo-policy-analysis-overview-service';
import type { CveEnrichmentService } from './cve/cve-enrichment-service';
import { NvdCveClientError } from './cve/nvd-cve-client';
+import type { GpoAutomaticAnalysisService } from './gpo/gpo-automatic-analysis-service';
import type { MicrosoftSecurityBaselineSelectionContext } from '../src/domain/microsoft-security-baseline';
import { listProjectGpoBackupStatus } from './gpo/gpo-backup-status-service';
import { directImportExecutor, type ImportExecutor } from './import-executor';
import { createCanonicalImportBatch } from '../src/importers/canonical-import';
import { processingScopeIssues } from '../src/domain/processing-compatibility';
+import { ASSESSOR_PRODUCT_VERSION } from '../src/domain/assessor-release';
import { compareReimportSourceHashes } from '../src/domain/reimport-source';
import {
findPossibleDuplicateImportFile,
@@ -131,6 +133,7 @@ export interface AssessorHttpServerOptions {
gpoPolicyEvaluationService?: GpoPolicyEvaluationService;
gpoPolicyFindingService?: GpoPolicyFindingService;
gpoPolicyAnalysisOverviewService?: GpoPolicyAnalysisOverviewService;
+ automaticGpoAnalysis?: GpoAutomaticAnalysisService;
microsoftSecurityBaselineService?: MicrosoftSecurityBaselineService;
cveEnrichmentService?: CveEnrichmentService;
}
@@ -233,6 +236,7 @@ function unifiedQueryFrom(url: URL): UnifiedResultQuery {
return undefined;
};
return {
+ audience: url.searchParams.get('audience') === 'internal-analysis' ? 'internal-analysis' : 'result-db',
projectId: url.searchParams.get('projectId') ?? undefined,
assessmentId: url.searchParams.get('assessmentId') ?? undefined,
assessmentIds: many('assessmentIds'),
@@ -396,7 +400,7 @@ export function createAssessorHttpServer(options: AssessorHttpServerOptions): Se
if (method === 'GET' && segments.length === 1 && segments[0] === 'health') {
const result: AssessorHealthResponse = {
- status: 'ok', application: 'ASSESSOR', apiVersion: 1,
+ status: 'ok', application: 'ASSESSOR', productVersion: ASSESSOR_PRODUCT_VERSION, apiVersion: 1,
releaseId: options.releaseId,
developmentInstanceId: options.developmentInstanceId,
repositoryRevision: repository.revision, persistence: options.persistence ?? 'memory'
@@ -747,6 +751,16 @@ export function createAssessorHttpServer(options: AssessorHttpServerOptions): Se
status = 200; sendJson(response, status, { version: 1, record }, requestId); return;
}
+ if (segments[0] === 'projects' && segments[2] === 'gpo-backups' && segments.length === 5 && segments[4] === 'evaluate' && method === 'POST') {
+ if (!options.automaticGpoAnalysis) throw new HttpError(503, 'gpo_evaluation_unavailable', 'GPO evaluation unavailable.');
+ await readJson>(request, maximumBodyBytes);
+ const artifact = (await repository.listImportArtifacts(segments[1])).find(item => item.id === segments[3]);
+ if (!artifact) throw new RepositoryNotFoundError('GPO source missing.');
+ const runs = (await repository.listProcessingRuns(artifact.id)).filter(item => item.projectId === segments[1])
+ .sort((a, b) => b.completedAt.localeCompare(a.completedAt) || b.id.localeCompare(a.id));
+ if (!runs[0]) throw new HttpError(409, 'gpo_processing_required', 'Import processing required.');
+ status = 200; sendJson(response, status, await options.automaticGpoAnalysis.run(segments[1], runs[0].id), requestId); return;
+ }
if (segments[0] === 'projects' && segments[2] === 'gpo-backups' && segments.length === 5 && segments[4] === 'reprocess' && method === 'POST') {
if (!options.gpoBackupManagementService) throw new HttpError(503, 'gpo_management_unavailable', 'Die GPO-Verwaltung ist nicht konfiguriert.');
const body = await readJson<{ expectedLatestProcessingRunId: string }>(request, maximumBodyBytes);
@@ -766,7 +780,7 @@ export function createAssessorHttpServer(options: AssessorHttpServerOptions): Se
if (!options.gpoBackupManagementService) throw new HttpError(503, 'gpo_management_unavailable', 'Die GPO-Verwaltung ist nicht konfiguriert.');
const body = await readJson<{ artifactId: string; confirmDelete: true }>(request, maximumBodyBytes);
if (!body || body.confirmDelete !== true || body.artifactId !== segments[3]) throw new HttpError(400, 'gpo_delete_confirmation_invalid', 'Die Löschung wurde nicht für das exakte GPO-Artefakt bestätigt.');
- const result = await options.gpoBackupManagementService.deleteFailed(segments[1], segments[3]);
+ const result = await options.gpoBackupManagementService.delete(segments[1], segments[3]);
status = 200; sendJson(response, status, result, requestId); return;
}
if (segments[0] === 'projects' && segments[2] === 'gpo-backups' && segments.length === 4 && segments[3] === 'status' && method === 'GET') {
@@ -787,7 +801,14 @@ export function createAssessorHttpServer(options: AssessorHttpServerOptions): Se
const result: GpoBackupSubmissionResponse = await options.gpoBackupSubmissionService.submit({
projectId: segments[1], assessmentId: body.assessmentId, fileName: body.fileName, bytes, receivedAt: now().toISOString()
});
- status = 202; sendJson(response, status, result, requestId); return;
+ const evaluation = result.deduplicated && options.automaticGpoAnalysis
+ ? await (async () => {
+ const runs = (await repository.listProcessingRuns(result.artifactId))
+ .sort((left, right) => Date.parse(right.completedAt) - Date.parse(left.completedAt) || right.id.localeCompare(left.id));
+ return runs[0] ? options.automaticGpoAnalysis!.run(segments[1], runs[0].id) : undefined;
+ })()
+ : undefined;
+ status = 202; sendJson(response, status, { ...result, evaluation }, requestId); return;
}
if (segments.length === 1 && segments[0] === 'projects' && method === 'GET') {
status = 200; sendJson(response, status, await repository.listProjects(), requestId); return;
diff --git a/server/gpo/advanced-audit-parser.ts b/server/gpo/advanced-audit-parser.ts
index f1fa7e5..292edc5 100644
--- a/server/gpo/advanced-audit-parser.ts
+++ b/server/gpo/advanced-audit-parser.ts
@@ -159,6 +159,7 @@ export function reduceAdvancedAuditPolicy(
const conflicted = distinctCodes.length > 1;
const id = `gpo-policy-${createHash('sha256').update([
context.backupInstanceId,
+ context.artifactId,
document.sourceSha256,
first.subcategoryGuid,
ADVANCED_AUDIT_REDUCER.version
diff --git a/server/gpo/gpo-automatic-analysis-service.ts b/server/gpo/gpo-automatic-analysis-service.ts
new file mode 100644
index 0000000..8707004
--- /dev/null
+++ b/server/gpo/gpo-automatic-analysis-service.ts
@@ -0,0 +1,89 @@
+import type { AssessorRepository } from '../../src/persistence/assessor-repository';
+import { RepositoryNotFoundError } from '../../src/persistence/repository-errors';
+import { inferGpoEnvironmentContexts } from './gpo-environment-context';
+import { GpoPolicySnapshotService } from './gpo-policy-snapshot-service';
+import { GpoPolicyEvaluationService } from './gpo-policy-evaluation-service';
+import { GpoPolicyFindingService } from './gpo-policy-finding-service';
+import { buildGpoAnalysisSnapshots } from '../../src/gpo/snapshot-builder';
+
+export type AutomaticGpoAnalysisResult = {
+ state: 'context-required' | 'baseline-required' | 'review' | 'evaluated';
+ evaluationRunId?: string;
+ diagnosticCode?: string;
+};
+
+/** One uploaded backup set, one timeslot. Never combines unrelated historical scans. */
+export class GpoAutomaticAnalysisService {
+ private readonly active = new Map>();
+ constructor(private readonly repository: AssessorRepository,
+ private readonly snapshots: GpoPolicySnapshotService,
+ private readonly evaluations: GpoPolicyEvaluationService,
+ private readonly findings: GpoPolicyFindingService) {}
+
+ run(projectId: string, processingRunId: string): Promise {
+ const key = `${projectId}:${processingRunId}`;
+ const existing = this.active.get(key);
+ if (existing) return existing;
+ const operation = this.execute(projectId, processingRunId).finally(() => this.active.delete(key));
+ this.active.set(key, operation);
+ return operation;
+ }
+
+ async reprocessProject(projectId: string): Promise<{ evaluated: number; review: number; failed: number }> {
+ let evaluated = 0;
+ let review = 0;
+ let failed = 0;
+ const analyses = await this.repository.listGpoPolicyAnalyses(projectId);
+ const superseded = new Set(analyses.flatMap(item => item.run.supersedesAnalysisRunId
+ ? [item.run.supersedesAnalysisRunId]
+ : []));
+ for (const analysis of analyses.filter(item => !superseded.has(item.run.id))) {
+ try {
+ const result = await this.run(projectId, analysis.run.sourceProcessingRunId);
+ if (result.state === 'evaluated') evaluated += 1;
+ else review += 1;
+ } catch {
+ failed += 1;
+ }
+ }
+ return { evaluated, review, failed };
+ }
+
+ private async execute(projectId: string, processingRunId: string): Promise {
+ const analysis = (await this.repository.listGpoPolicyAnalyses(projectId))
+ .find(record => record.run.sourceProcessingRunId === processingRunId);
+ if (!analysis) throw new RepositoryNotFoundError('GPO analysis missing.');
+ const artifact = (await this.repository.listImportArtifacts(projectId)).find(record => record.id === analysis.run.artifactId);
+ if (!artifact?.assessmentId) return { state: 'context-required' };
+ const environment = await this.repository.getEnvironmentSnapshot({ projectId, assessmentId: artifact.assessmentId });
+ const observedContexts = inferGpoEnvironmentContexts(environment.observations);
+ const contexts = [...observedContexts, {
+ id: 'gpo-baseline-comparison', kind: 'operating-system' as const,
+ productFamily: 'Group Policy', productVersion: 'All imported baselines', role: 'Any', scope: 'mixed' as const
+ }].filter((context, index, all) => all.findIndex(candidate => candidate.id === context.id) === index);
+ const instances = (await this.repository.listGpoBackupInstances(projectId))
+ .filter(item => item.processingRunId === processingRunId);
+ const snapshotCandidates = buildGpoAnalysisSnapshots(instances.map(item => item.instance), { createdAt: analysis.run.completedAt });
+ if (snapshotCandidates.length !== 1) return { state: 'review', diagnosticCode: 'policy-aggregation-multiple-snapshots' };
+ const profile = await this.snapshots.createEnvironmentProfile(projectId, {
+ name: `Detected environment · ${artifact.assessmentId}`, contexts
+ });
+ const baselines = await this.repository.listMicrosoftSecurityBaselines();
+ const eligibleBaselineIds = new Set(baselines.filter(record => record.status === 'eligible').map(record => record.id));
+ if (!eligibleBaselineIds.size) return { state: 'baseline-required' };
+ const analyses = await this.repository.listMicrosoftSecurityBaselineAnalyses();
+ const superseded = new Set(analyses.flatMap(item => item.supersedesAnalysisId ? [item.supersedesAnalysisId] : []));
+ const baselineAnalysisIds = analyses.filter(item => eligibleBaselineIds.has(item.analysis.baselineId)
+ && !superseded.has(item.analysis.id))
+ .map(item => item.analysis.id).sort();
+ if (!baselineAnalysisIds.length) return { state: 'baseline-required' };
+ const aggregation = await this.snapshots.aggregate(projectId, {
+ environmentProfileId: profile.id, sourceAnalysisRunIds: [analysis.run.id]
+ });
+ const evaluation = await this.evaluations.evaluate(projectId, {
+ aggregationRunId: aggregation.run.id, baselineAnalysisIds: [...new Set(baselineAnalysisIds)].sort()
+ });
+ await this.findings.create(projectId, { evaluationRunId: evaluation.run.id });
+ return { state: evaluation.run.status === 'complete' ? 'evaluated' : 'review', evaluationRunId: evaluation.run.id };
+ }
+}
diff --git a/server/gpo/gpo-backup-ingestion.ts b/server/gpo/gpo-backup-ingestion.ts
index 581f0ef..746c88f 100644
--- a/server/gpo/gpo-backup-ingestion.ts
+++ b/server/gpo/gpo-backup-ingestion.ts
@@ -87,7 +87,8 @@ export function ingestGpoBackupContainer(bytes: Uint8Array, options: GpoBackupIn
bytes,
selectedPaths,
options.resourcePolicy,
- options.maximumSelectedArtifactBytes ?? options.maximumMetadataBytes ?? 16 * 1024 * 1024
+ options.maximumSelectedArtifactBytes ?? options.maximumMetadataBytes
+ ?? Math.min(options.resourcePolicy?.maximumZipUncompressedBytes ?? 512 * 1024 * 1024, 128 * 1024 * 1024)
);
const retainIntermediateDocuments = options.retainIntermediateDocuments ?? true;
const metadataPathSet = new Set(metadataPaths);
diff --git a/server/gpo/gpo-backup-job-processor.ts b/server/gpo/gpo-backup-job-processor.ts
index 8a42027..8212c36 100644
--- a/server/gpo/gpo-backup-job-processor.ts
+++ b/server/gpo/gpo-backup-job-processor.ts
@@ -9,13 +9,14 @@ import type { BackendArtifactStore } from '../artifacts/backend-artifact-store';
import { GPO_BACKUP_ANALYZER_VERSION } from './gpo-backup-submission-service';
import type { GpoBackupWorkerExecutor } from './gpo-inventory-executor';
-export const GPO_BACKUP_JOB_PROCESSOR_VERSION = '2.0.0';
+export const GPO_BACKUP_JOB_PROCESSOR_VERSION = '2.2.2';
export interface GpoBackupJobProcessorOptions {
leaseDurationMs?: number;
retryDelayMs?: number;
maximumArtifactBytes: number;
now?: () => Date;
+ afterAnalysis?: (projectId: string, processingRunId: string) => Promise;
}
export interface GpoBackupJobProcessResult {
@@ -47,7 +48,7 @@ export class GpoBackupJobProcessor {
private readonly repository: AssessorRepository,
private readonly artifactStore: BackendArtifactStore,
private readonly executor: GpoBackupWorkerExecutor,
- options: GpoBackupJobProcessorOptions
+ private readonly options: GpoBackupJobProcessorOptions
) {
this.leaseDurationMs = options.leaseDurationMs ?? 60_000;
this.retryDelayMs = options.retryDelayMs ?? 5_000;
@@ -61,10 +62,11 @@ export class GpoBackupJobProcessor {
}
}
- async processNext(workerId: string): Promise {
+ async processNext(workerId: string, projectId?: string): Promise {
const claimedAt = this.now().toISOString();
const job = await this.repository.claimNextIngestionJob({
workerId,
+ projectId,
now: claimedAt,
leaseDurationMs: this.leaseDurationMs,
kinds: ['analyze-gpo-backup']
@@ -75,6 +77,7 @@ export class GpoBackupJobProcessor {
if (!job.artifactId) throw new RepositoryValidationError('Der GPO-Analysejob besitzt kein Artefakt.');
const existingRun = (await this.repository.listProcessingRuns(job.artifactId)).find(run => run.id === processingRunId);
if (existingRun) {
+ await this.options.afterAnalysis?.(job.projectId, processingRunId);
const completed = await this.repository.completeIngestionJob(job.id, workerId, this.now().toISOString());
const existingInstances = (await this.repository.listGpoBackupInstances(job.projectId))
.filter(record => record.processingRunId === processingRunId);
@@ -160,6 +163,7 @@ export class GpoBackupJobProcessor {
resolutions: storedResolutions
};
await this.repository.saveGpoBackupAnalysis(run, instances, policyAnalysis);
+ await this.options.afterAnalysis?.(job.projectId, processingRunId);
const completed = await this.repository.completeIngestionJob(job.id, workerId, this.now().toISOString());
return { jobId: job.id, status: completed.status, processingRunId, backupInstanceCount: instances.length };
} catch (error) {
@@ -204,4 +208,3 @@ export class GpoBackupJobRunner {
await this.active;
}
}
-
diff --git a/server/gpo/gpo-backup-management-service.ts b/server/gpo/gpo-backup-management-service.ts
index 9038f4a..8d88d47 100644
--- a/server/gpo/gpo-backup-management-service.ts
+++ b/server/gpo/gpo-backup-management-service.ts
@@ -45,7 +45,7 @@ export class GpoBackupManagementService {
supersedesProcessingRunId: latest.id
};
}
- async deleteFailed(projectId: string, artifactId: string) {
+ async delete(projectId: string, artifactId: string) {
const artifact = (await this.repository.listImportArtifacts(projectId)).find(item => item.id === artifactId);
if (!artifact || artifact.storage.kind !== 'backend-controlled') throw new RepositoryNotFoundError('Das GPO-Artefakt ist im Mandanten nicht vorhanden.');
const timestamp = this.now().toISOString();
@@ -59,7 +59,7 @@ export class GpoBackupManagementService {
nextAttemptAt: timestamp,
createdAt: timestamp
};
- const deleted = await this.repository.deleteFailedGpoArtifact(projectId, artifactId, request);
+ const deleted = await this.repository.deleteGpoArtifact(projectId, artifactId, request);
const storageRemoval = await processArtifactDeletionRequest(this.repository, this.artifactStore, deleted.request, this.now);
return { version: 1 as const, artifactId, deleted: true as const, storageRemoval };
}
diff --git a/server/gpo/gpo-backup-submission-service.ts b/server/gpo/gpo-backup-submission-service.ts
index 60f218a..8d5259a 100644
--- a/server/gpo/gpo-backup-submission-service.ts
+++ b/server/gpo/gpo-backup-submission-service.ts
@@ -6,7 +6,7 @@ import { RepositoryNotFoundError, RepositoryValidationError } from '../../src/pe
import type { BackendArtifactStore } from '../artifacts/backend-artifact-store';
import type { GpoInventoryExecutor } from './gpo-inventory-executor';
-export const GPO_BACKUP_ANALYZER_VERSION = 'gpo-backup-policy-analysis:2.0.0';
+export const GPO_BACKUP_ANALYZER_VERSION = 'gpo-backup-policy-analysis:2.2.2';
export interface SubmitGpoBackupRequest {
projectId: string;
diff --git a/server/gpo/gpo-environment-context.ts b/server/gpo/gpo-environment-context.ts
new file mode 100644
index 0000000..b60d7b2
--- /dev/null
+++ b/server/gpo/gpo-environment-context.ts
@@ -0,0 +1,30 @@
+import { createHash } from 'node:crypto';
+import type { EnvironmentObservation } from '../../src/domain/environment-context';
+import type { EnvironmentProfileContext } from '../../src/domain/gpo-snapshot-aggregation';
+
+/** Observed platform inventory is evidence for candidate contexts, not GPO applicability. */
+export function inferGpoEnvironmentContexts(observations: EnvironmentObservation[]): Array> {
+ const contexts = new Map>();
+ for (const observation of observations) {
+ if (observation.state !== 'observed' || observation.property !== 'operating_system.name') continue;
+ const value = observation.normalizedValue ?? observation.originalValue;
+ if (typeof value !== 'string') continue;
+ const isDc = observation.subject.type === 'computer-information.domain-controllers';
+ const server = /^Windows(?: Server)? (2008(?: R2)?|2012(?: R2)?|2016|2019|2022|2025)(?:\b|$)/i.exec(value.trim());
+ // A generic server inventory row does not prove member-server role.
+ if (!isDc || !server) continue;
+ const productVersion = server[1].toUpperCase();
+ const key = `Windows Server:${productVersion}:Domain Controller`;
+ const existing = contexts.get(key);
+ if (existing) {
+ existing.sourceObservationIds = [...new Set([...(existing.sourceObservationIds ?? []), observation.id])].sort();
+ continue;
+ }
+ contexts.set(key, {
+ id: 'detected-context-' + createHash('sha256').update(key).digest('hex').slice(0, 24),
+ kind: 'operating-system', productFamily: 'Windows Server', productVersion,
+ role: 'Domain Controller', scope: 'computer', sourceObservationIds: [observation.id]
+ });
+ }
+ return [...contexts.values()].sort((a, b) => a.id.localeCompare(b.id));
+}
diff --git a/server/gpo/gpo-inventory-executor.ts b/server/gpo/gpo-inventory-executor.ts
index 95cf394..f584fee 100644
--- a/server/gpo/gpo-inventory-executor.ts
+++ b/server/gpo/gpo-inventory-executor.ts
@@ -8,7 +8,7 @@ import {
} from './gpo-container-inventory';
import { ingestGpoBackupContainer, type GpoBackupIngestionOptions } from './gpo-backup-ingestion';
import type { GpoBackupInstance } from '../../src/domain/gpo-ingestion';
-import { resolveRegistryPolicyIdentity } from './admx-policy-catalog';
+import { resolvePolicyTarget } from './policy-target-resolver';
import {
analyzeMicrosoftSecurityBaselinePackage,
type MicrosoftSecurityBaselineAnalysisOptions
@@ -88,9 +88,7 @@ export function analyzeGpoBackupForPersistence(request: GpoBackupWorkerExecution
const identityResolutions = analysis.backupInstances.flatMap(instance => (instance.policyObservations ?? []).map(observation => ({
backupInstanceId: instance.id,
observationId: observation.id,
- resolution: observation.deliveryMechanism === 'registry-policy'
- ? resolveRegistryPolicyIdentity(observation)
- : { version: 1 as const, status: 'unresolved' as const, reasonCode: `identity-resolver-unsupported-${observation.deliveryMechanism}` }
+ resolution: resolvePolicyTarget(observation)
})));
return {
version: 1,
@@ -124,4 +122,4 @@ export const directGpoBackupWorkerExecutor: GpoBackupWorkerExecutor & MicrosoftB
executeMicrosoftBaseline(request) {
return Promise.resolve(analyzeMicrosoftSecurityBaselinePackage(request.bytes, request.options));
}
-};
\ No newline at end of file
+};
diff --git a/server/gpo/gpo-metadata-parser.ts b/server/gpo/gpo-metadata-parser.ts
index 4f3399b..88d1861 100644
--- a/server/gpo/gpo-metadata-parser.ts
+++ b/server/gpo/gpo-metadata-parser.ts
@@ -1,11 +1,12 @@
-import { JSDOM } from 'jsdom';
+import { SaxesParser } from 'saxes';
import type { GpoBackupMetadataDocument } from '../../src/domain/gpo-metadata';
import type { ImportResourcePolicy } from '../../src/importers/resource-policy';
import { resolveImportResourcePolicy, validateDecodedTextResources } from '../../src/importers/resource-policy';
import { ImportError } from '../../src/shared/errors';
import type { VerifiedZipFile } from './zip-inventory';
-const parser = { id: 'gpo-backup-metadata-xml', version: '1.0.0' } as const;
+const parser = { id: 'gpo-backup-metadata-xml', version: '1.2.0' } as const;
+const maximumMetadataBytes = 64 * 1024 * 1024;
const guidPattern = /^\{?([a-f0-9]{8}-[a-f0-9]{4}-[1-5][a-f0-9]{3}-[89ab][a-f0-9]{3}-[a-f0-9]{12})\}?$/i;
const dnsPattern = /^(?=.{1,253}$)(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?$/i;
@@ -14,7 +15,7 @@ function parserError(code: string, message: string, details: Record 2 * 1024 * 1024) parserError('gpo-metadata-size-limit', 'Eine GPO-Metadatendatei überschreitet das Größenlimit.', { sizeBytes: bytes.byteLength });
+ if (bytes.byteLength > maximumMetadataBytes) parserError('gpo-metadata-size-limit', 'Eine GPO-Metadatendatei überschreitet das Größenlimit.', { sizeBytes: bytes.byteLength });
let encoding = 'utf-8';
let content = bytes;
if (bytes[0] === 0xff && bytes[1] === 0xfe) { encoding = 'utf-16le'; content = bytes.subarray(2); }
@@ -87,8 +88,8 @@ export function parseGpoBackupMetadataXml(
const text = decodeXml(file.bytes);
const policy = resolveImportResourcePolicy({
...resourceOverrides,
- maximumDecodedCharacters: Math.min(resourceOverrides?.maximumDecodedCharacters ?? 2 * 1024 * 1024, 2 * 1024 * 1024),
- maximumMarkupElements: Math.min(resourceOverrides?.maximumMarkupElements ?? 20_000, 20_000)
+ maximumDecodedCharacters: Math.min(resourceOverrides?.maximumDecodedCharacters ?? maximumMetadataBytes, maximumMetadataBytes),
+ maximumMarkupElements: Math.min(resourceOverrides?.maximumMarkupElements ?? 500_000, 500_000)
});
validateDecodedTextResources(text, 'xml', policy);
if (/<\s*(?:[A-Za-z_][\w.-]*:)?include\b/i.test(text)
@@ -96,33 +97,51 @@ export function parseGpoBackupMetadataXml(
|| /<\?(?!xml(?:\s|\?>))/i.test(text)) {
parserError('gpo-metadata-external-reference-rejected', 'Externe Includes, Schemas und Verarbeitungsanweisungen sind in GPO-Metadaten nicht zulässig.');
}
- let dom: JSDOM;
- try {
- dom = new JSDOM(text, { contentType: 'text/xml' });
- } catch {
- parserError('gpo-metadata-xml-invalid', 'Die GPO-Metadatendatei ist kein wohlgeformtes XML.');
- }
- const document = dom.window.document;
- try {
- if (document.getElementsByTagName('parsererror').length) parserError('gpo-metadata-xml-invalid', 'Die GPO-Metadatendatei ist kein wohlgeformtes XML.');
const diagnostics = new Set();
const values = new Map();
let secretIndicatorStatus: GpoBackupMetadataDocument['secretIndicatorStatus'] = 'not-detected';
- for (const element of [...document.getElementsByTagName('*')]) {
- const name = element.localName.toLocaleLowerCase('en-US');
- if (name === 'cpassword' || [...element.attributes].some(attribute => attribute.localName.toLocaleLowerCase('en-US') === 'cpassword')) {
+ // Retain only bounded identity fields, never the full report tree or secret values.
+ const stack: Array<{ name: string; field?: string; selected: boolean; nested: boolean; text: string }> = [];
+ const xml = new SaxesParser({ xmlns: true });
+ xml.on('error', () => parserError('gpo-metadata-xml-invalid', 'Die GPO-Metadatendatei ist kein wohlgeformtes XML.'));
+ xml.on('doctype', () => parserError('gpo-metadata-external-reference-rejected', 'DTD ist in GPO-Metadaten nicht zulässig.'));
+ xml.on('opentag', element => {
+ if (stack.length >= 128) parserError('gpo-metadata-depth-limit', 'GPO-Metadaten sind zu tief verschachtelt.');
+ const parent = stack[stack.length - 1];
+ if (parent) parent.nested = true;
+ const name = element.local.toLocaleLowerCase('en-US');
+ if (name === 'cpassword' || Object.values(element.attributes).some(attribute => attribute.local.toLocaleLowerCase('en-US') === 'cpassword')) {
secretIndicatorStatus = 'present';
diagnostics.add('gpo-secret-indicator-present');
}
- if (!['gpoid', 'gpoguid', 'backupid', 'id', 'gpodomain', 'gpodomainguid', 'domainname', 'backuptime'].includes(name)) continue;
- if (name === 'id' && element.parentElement?.localName.toLocaleLowerCase('en-US') !== 'backupinst') continue;
- const value = element.textContent?.trim() ?? '';
- if (!value || value.length > 2048 || element.children.length) {
+ const path = [...stack.map(item => item.name), name].join('/');
+ const core = 'grouppolicybackupscheme/grouppolicyobject/grouppolicycoresettings/';
+ const field = path === core + 'id' || path === 'gpo/identifier/identifier' ? 'gpoid'
+ : path === core + 'domain' || path === 'gpo/identifier/domain' ? 'gpodomain'
+ : name === 'id' && parent?.name === 'backupinst' ? 'backupid'
+ : ['gpoid', 'gpoguid', 'backupid', 'gpodomain', 'gpodomainguid', 'domainname', 'backuptime'].includes(name) ? name : undefined;
+ stack.push({ name, field, selected: field !== undefined, nested: false, text: '' });
+ });
+ const onText = (value: string) => {
+ const current = stack[stack.length - 1];
+ if (current?.selected) current.text = (current.text + value).slice(0, 2049);
+ };
+ xml.on('text', onText);
+ xml.on('cdata', onText);
+ xml.on('closetag', () => {
+ const current = stack.pop()!;
+ if (!current.selected) return;
+ const value = current.text.trim();
+ if (!value || current.text.length > 2048 || current.nested) {
diagnostics.add('gpo-metadata-field-shape-invalid');
- continue;
+ return;
}
- values.set(name, [...(values.get(name) ?? []), value]);
- }
+ const entries = values.get(current.field!) ?? [];
+ entries.push(value);
+ values.set(current.field!, entries);
+ });
+ for (let offset = 0; offset < text.length; offset += 64 * 1024) xml.write(text.slice(offset, offset + 64 * 1024));
+ xml.close();
const gpoId = uniqueGuid([...(values.get('gpoid') ?? []), ...(values.get('gpoguid') ?? [])], diagnostics, 'gpo-id');
const backupId = uniqueGuid([...(values.get('backupid') ?? []), ...(values.get('id') ?? [])], diagnostics, 'backup-id');
const domainKey = canonicalDomain(values, diagnostics);
@@ -145,7 +164,4 @@ export function parseGpoBackupMetadataXml(
secretIndicatorStatus,
diagnosticCodes: [...diagnostics].sort()
};
- } finally {
- dom.window.close();
- }
}
diff --git a/server/gpo/gpo-policy-evaluation-rule-engine.ts b/server/gpo/gpo-policy-evaluation-rule-engine.ts
index 3ebf2e8..d7724bc 100644
--- a/server/gpo/gpo-policy-evaluation-rule-engine.ts
+++ b/server/gpo/gpo-policy-evaluation-rule-engine.ts
@@ -11,6 +11,7 @@ import {
export interface PolicyRuleResolution {
baselineState: PolicyBaselineState;
comparator: PolicyComparatorDefinition;
+ source: 'baseline-setting' | 'rule-catalog';
ruleIds: string[];
dependencyRuleIds: string[];
riskRuleIds: string[];
@@ -73,6 +74,7 @@ export function resolvePolicyEvaluationRule(
): PolicyRuleResolution {
const diagnostics = new Set();
const selected: PolicyEvaluationRule[] = [];
+ let missingContextRules = 0;
for (const contextId of state.applicableContextIds) {
const context = profile.contexts.find(candidate => candidate.id === contextId);
if (!context) {
@@ -83,20 +85,25 @@ export function resolvePolicyEvaluationRule(
catalog, state.identity.id, state.deliveryMechanism, context, state.identity.scope
);
if (candidates.length !== 1) {
- diagnostics.add(candidates.length
- ? 'policy-evaluation-rule-ambiguous'
- : 'policy-evaluation-rule-catalog-gap');
+ if (candidates.length) diagnostics.add('policy-evaluation-rule-ambiguous');
+ else missingContextRules += 1;
continue;
}
selected.push(candidates[0]);
}
const rules = [...new Map(selected.map(rule => [rule.id, rule])).values()]
.sort((left, right) => left.id.localeCompare(right.id));
+ const useBaselineSetting = rules.length === 0
+ && missingContextRules === state.applicableContextIds.length
+ && !diagnostics.size;
+ if (!useBaselineSetting && missingContextRules > 0) {
+ diagnostics.add('policy-evaluation-rule-catalog-gap');
+ }
const dispositions = new Set(rules.map(rule => rule.baselineDisposition));
if (dispositions.size > 1) diagnostics.add('policy-evaluation-rule-context-conflict');
let baselineState: PolicyBaselineState = dispositions.size === 1
? rules[0].baselineDisposition
- : 'catalog-gap';
+ : useBaselineSetting ? 'explicit-recommendation' : 'catalog-gap';
const recommendationRules = rules.filter(rule => rule.baselineDisposition === 'explicit-recommendation');
const comparatorSignatures = new Set(recommendationRules.map(rule => canonicalJson(rule.comparator)));
if (comparatorSignatures.size > 1) diagnostics.add('policy-evaluation-comparator-consensus-conflict');
@@ -121,7 +128,8 @@ export function resolvePolicyEvaluationRule(
const comparator = recommendationRules[0]?.comparator ?? { kind: 'equality' as const };
return {
baselineState,
- comparator,
+ comparator: useBaselineSetting ? { kind: 'equality' } : comparator,
+ source: useBaselineSetting ? 'baseline-setting' : 'rule-catalog',
ruleIds: rules.map(rule => rule.id),
dependencyRuleIds: dependencies.map(rule => rule.id),
riskRuleIds: sortedUnique(recommendationRules.flatMap(rule => rule.riskRule ? [rule.riskRule.id] : [])),
diff --git a/server/gpo/gpo-policy-evaluation-service.ts b/server/gpo/gpo-policy-evaluation-service.ts
index dda246c..a2b1d5d 100644
--- a/server/gpo/gpo-policy-evaluation-service.ts
+++ b/server/gpo/gpo-policy-evaluation-service.ts
@@ -2,7 +2,7 @@ import { createHash } from 'node:crypto';
import type { AssessorRepository } from '../../src/persistence/assessor-repository';
import { RepositoryNotFoundError, RepositoryValidationError } from '../../src/persistence/repository-errors';
import { canonicalJson } from '../../src/shared/canonical-json';
-import { baselineProductContexts, type MicrosoftSecurityBaselineRecord } from '../../src/domain/microsoft-security-baseline';
+import type { MicrosoftSecurityBaselineRecord } from '../../src/domain/microsoft-security-baseline';
import type { StoredMicrosoftSecurityBaselineAnalysis, MicrosoftSecurityBaselineSetting } from '../../src/domain/microsoft-security-baseline-analysis';
import type { AggregatedPolicyState, EnvironmentProfile, StoredPolicySnapshotAggregation } from '../../src/domain/gpo-snapshot-aggregation';
import {
@@ -23,7 +23,6 @@ import {
policyEvaluationRuleCatalogValidationErrors,
type PolicyEvaluationRuleCatalog
} from '../../src/domain/policy-evaluation-rules';
-import { resolvePolicyEvaluationRule } from './gpo-policy-evaluation-rule-engine';
function stableId(prefix: string, value: string): string {
return prefix + '-' + createHash('sha256').update(value).digest('hex').slice(0, 32);
@@ -33,19 +32,6 @@ function sortedUnique(values: string[]): string[] {
return [...new Set(values)].sort((left, right) => left.localeCompare(right));
}
-function normalized(value: string): string {
- return value.trim().toLocaleLowerCase('en-US').replace(/[^a-z0-9]+/g, ' ').trim();
-}
-
-function baselineMatchesContext(record: MicrosoftSecurityBaselineRecord, context: EnvironmentProfile['contexts'][number], scope: 'computer' | 'user'): boolean {
- return baselineProductContexts(record.metadata).some(candidate =>
- normalized(candidate.productFamily) === normalized(context.productFamily)
- && normalized(candidate.productVersion) === normalized(context.productVersion)
- && candidate.roles.some(role => normalized(role) === 'any' || normalized(role) === normalized(context.role))
- && (candidate.scopes.includes('mixed') || candidate.scopes.includes(scope))
- );
-}
-
interface EvaluationBuildInput {
profile: EnvironmentProfile;
aggregation: StoredPolicySnapshotAggregation;
@@ -71,115 +57,77 @@ function evidenceFor(resultId: string, inputs: EvaluationEvidenceInput[]): Polic
})));
}
-function resolvedSettings(analysis: StoredMicrosoftSecurityBaselineAnalysis, identityId: string): MicrosoftSecurityBaselineSetting[] {
- return analysis.analysis.settings.filter(setting =>
- setting.identity.status === 'resolved' && setting.identity.identity.id === identityId
- ).sort((left, right) => left.id.localeCompare(right.id));
-}
-
-function evaluateState(
+function evaluateBaselineIdentity(
runId: string,
- input: EvaluationBuildInput,
- state: AggregatedPolicyState,
- analysesById: Map,
- recordsById: Map
+ analysis: StoredMicrosoftSecurityBaselineAnalysis,
+ baseline: MicrosoftSecurityBaselineRecord,
+ settings: MicrosoftSecurityBaselineSetting[],
+ state: AggregatedPolicyState | undefined
): { result: PolicyEvaluationResult; evidence: PolicyEvaluationEvidence[] } {
const diagnostics = new Set();
- const rule = resolvePolicyEvaluationRule(input.ruleCatalog, input.profile, input.aggregation, state);
- rule.diagnosticCodes.forEach(code => diagnostics.add(code));
- let baselineState = rule.baselineState;
- const applicableContexts = state.applicableContextIds.map(id => input.profile.contexts.find(context => context.id === id));
- if (applicableContexts.some(context => !context)) diagnostics.add('policy-evaluation-context-missing');
- if (input.aggregation.run.status !== 'complete' || input.aggregation.snapshot.completeness !== 'complete') {
- diagnostics.add('policy-evaluation-snapshot-incomplete');
+ const identity = settings[0].identity.status === 'resolved' ? settings[0].identity.identity : undefined;
+ if (!identity) throw new RepositoryValidationError('Eine Baselinegruppe besitzt keine aufgeloeste technische Identitaet.');
+ if (analysis.analysis.status !== 'complete' || analysis.analysis.admxCatalog.status !== 'complete') {
+ diagnostics.add('policy-evaluation-baseline-incomplete');
}
- if (state.status !== 'configured' || state.completeness !== 'complete' || state.targeting !== 'none') {
- diagnostics.add(state.status === 'conflicted' ? 'policy-evaluation-customer-conflict'
- : state.status === 'deleted' ? 'policy-evaluation-deleted-state-review'
- : 'policy-evaluation-customer-state-incomplete');
- }
-
- const usedAnalyses: StoredMicrosoftSecurityBaselineAnalysis[] = [];
- const usedSettings: MicrosoftSecurityBaselineSetting[] = [];
- for (const context of applicableContexts) {
- if (!context) continue;
- const candidates = input.baselineAnalyses.filter(analysis => {
- const record = recordsById.get(analysis.analysis.baselineId);
- return Boolean(record && baselineMatchesContext(record, context, state.identity.scope));
- });
- if (candidates.length !== 1) {
- diagnostics.add(candidates.length ? 'policy-evaluation-baseline-ambiguous' : 'policy-evaluation-baseline-missing');
- continue;
- }
- const analysis = analysesById.get(candidates[0].analysis.id)!;
- usedAnalyses.push(analysis);
- if (analysis.analysis.status !== 'complete' || analysis.analysis.admxCatalog.status !== 'complete') {
- diagnostics.add('policy-evaluation-baseline-incomplete');
- baselineState = 'parser-gap';
- }
- if (rule.baselineState === 'explicit-recommendation') {
- const settings = resolvedSettings(analysis, state.identity.id);
- if (!settings.length) {
- diagnostics.add('policy-evaluation-baseline-recommendation-missing');
- baselineState = 'catalog-gap';
- }
- usedSettings.push(...settings);
- }
- }
-
- const uniqueAnalyses = [...new Map(usedAnalyses.map(analysis => [analysis.analysis.id, analysis])).values()];
- const uniqueSettings = [...new Map(usedSettings.map(setting => [setting.id, setting])).values()];
- const recommendationSignatures = new Set(uniqueSettings.map(setting => canonicalJson(setting.observation.values[0])));
+ const recommendationSignatures = new Set(settings.map(setting => canonicalJson(setting.observation.values[0])));
if (recommendationSignatures.size > 1) diagnostics.add('policy-evaluation-baseline-consensus-conflict');
- const customerSignatures = new Set(state.values.map(value => canonicalJson(value)));
- if (rule.baselineState === 'explicit-recommendation' && customerSignatures.size !== 1) {
- diagnostics.add('policy-evaluation-customer-value-ambiguous');
- }
+ const customerSignatures = new Set(state?.values.map(value => canonicalJson(value)) ?? []);
+ if (state && customerSignatures.size !== 1) diagnostics.add('policy-evaluation-customer-value-ambiguous');
+ const customerState: PolicyEvaluationResult['customerState'] = !state || state.status === 'deleted'
+ ? 'missing'
+ : state.status === 'conflicted' ? 'conflicted'
+ : state.status === 'indeterminate' ? 'indeterminate' : 'configured';
+ if (customerState === 'conflicted') diagnostics.add('policy-evaluation-customer-conflict');
+ if (customerState === 'indeterminate') diagnostics.add('policy-evaluation-customer-state-incomplete');
let compared: PolicyComparatorOutcome = {
version: 1,
- comparator: rule.comparator,
- relation: 'incomparable',
+ comparator: { kind: 'equality' },
+ relation: customerState === 'missing' ? 'different' : 'incomparable',
+ baseline: undefined,
diagnosticCodes: []
};
- if (!diagnostics.size && rule.baselineState === 'explicit-recommendation' && !rule.notApplicable) {
- compared = comparePolicyValues(state.values[0], uniqueSettings[0]?.observation.values[0], rule.comparator);
- if (compared.diagnosticCodes.length) baselineState = 'unsupported-setting';
+ if (recommendationSignatures.size === 1 && customerState === 'missing') {
+ compared = comparePolicyValues(undefined, settings[0].observation.values[0], { kind: 'equality' });
+ if (compared.baseline !== undefined) {
+ compared = { ...compared, relation: 'different', diagnosticCodes: [] };
+ } else {
+ compared.diagnosticCodes.forEach(code => diagnostics.add(code));
+ }
+ } else if (recommendationSignatures.size === 1 && customerState === 'configured' && customerSignatures.size === 1 && state) {
+ compared = comparePolicyValues(state.values[0], settings[0].observation.values[0], { kind: 'equality' });
compared.diagnosticCodes.forEach(code => diagnostics.add(code));
}
- const review = diagnostics.size > 0
- || (!rule.notApplicable && rule.baselineState === 'explicit-recommendation' && compared.relation === 'incomparable');
+ const review = recommendationSignatures.size !== 1 || ['conflicted', 'indeterminate'].includes(customerState)
+ || compared.relation === 'incomparable';
const classification: PolicyEvaluationResult['classification'] = review
? 'review_required'
- : rule.notApplicable
- ? 'not_applicable'
- : rule.baselineState !== 'explicit-recommendation'
- ? 'review_required'
- : compared.relation === 'match' || compared.relation === 'stronger'
- ? 'configured_match'
- : 'confirmed_configured_deviation';
- const resultId = stableId('policy-evaluation-result', runId + '\0' + state.id);
- const baselineAnalysisIds = sortedUnique(uniqueAnalyses.map(analysis => analysis.analysis.id));
- const baselineSettingIds = sortedUnique(uniqueSettings.map(setting => setting.id));
+ : compared.relation === 'match' ? 'configured_match' : 'confirmed_configured_deviation';
+ const resultId = stableId('policy-evaluation-result', runId + '\0' + analysis.analysis.id + '\0' + identity.id);
+ const baselineAnalysisIds = [analysis.analysis.id];
+ const baselineSettingIds = sortedUnique(settings.map(setting => setting.id));
const result: PolicyEvaluationResult = {
version: 1,
id: resultId,
evaluationRunId: runId,
- aggregationStateId: state.id,
- identity: state.identity,
+ aggregationStateId: customerState === 'missing' ? undefined : state?.id,
+ baselineAnalysisId: analysis.analysis.id,
+ baselineId: baseline.id,
+ baselineLabel: baseline.fileName.replace(/\.zip$/i, ''),
+ customerState,
+ identity,
classification,
- baselineState,
+ baselineState: compared.diagnosticCodes.length ? 'unsupported-setting' : 'explicit-recommendation',
comparator: compared,
- ruleIds: rule.ruleIds,
- dependencyRuleIds: rule.dependencyRuleIds,
- riskRuleIds: rule.riskRuleIds,
- contextIds: sortedUnique(state.applicableContextIds),
- observationIds: sortedUnique(state.observationIds),
- backupInstanceIds: sortedUnique(state.backupInstanceIds),
+ ruleIds: [],
+ dependencyRuleIds: [],
+ riskRuleIds: [],
+ contextIds: sortedUnique(state?.applicableContextIds ?? []),
+ observationIds: customerState === 'missing' ? [] : sortedUnique(state?.observationIds ?? []),
+ backupInstanceIds: customerState === 'missing' ? [] : sortedUnique(state?.backupInstanceIds ?? []),
baselineAnalysisIds,
baselineSettingIds,
- findingEligibility: classification === 'confirmed_configured_deviation' && rule.riskRuleIds.length
- ? 'eligible'
- : 'ineligible',
+ findingEligibility: 'ineligible',
effectiveState: 'unknown',
diagnosticCodes: [...diagnostics].sort()
};
@@ -209,9 +157,23 @@ export function buildPolicyEvaluation(input: EvaluationBuildInput): StoredPolicy
canonicalJson(input.ruleCatalog),
...baselineAnalysisIds
].join('\0'));
- const analysesById = new Map(input.baselineAnalyses.map(record => [record.analysis.id, record]));
- const recordsById = new Map(input.baselineRecords.map(record => [record.id, record]));
- const built = input.aggregation.states.map(state => evaluateState(runId, input, state, analysesById, recordsById));
+ const statesByIdentity = new Map(input.aggregation.states.map(state => [state.identity.id, state]));
+ const baselinesById = new Map(input.baselineRecords.map(record => [record.id, record]));
+ const built = input.baselineAnalyses.flatMap(analysis => {
+ const baseline = baselinesById.get(analysis.analysis.baselineId);
+ if (!baseline) throw new RepositoryValidationError('Eine Baselineanalyse verweist auf keinen Baselinekatalogeintrag.');
+ const grouped = new Map();
+ for (const setting of analysis.analysis.settings) {
+ if (setting.identity.status !== 'resolved') continue;
+ // A structurally parsed baseline row without an actual Microsoft
+ // recommendation is not a benchmark and must not produce PASS/FAIL.
+ if (setting.observation.values[0] === undefined) continue;
+ const id = setting.identity.identity.id;
+ grouped.set(id, [...(grouped.get(id) ?? []), setting]);
+ }
+ return [...grouped.entries()].sort(([left], [right]) => left.localeCompare(right))
+ .map(([identityId, settings]) => evaluateBaselineIdentity(runId, analysis, baseline, settings, statesByIdentity.get(identityId)));
+ });
const results = built.map(item => item.result).sort((left, right) => left.id.localeCompare(right.id));
const evidence = built.flatMap(item => item.evidence).sort((left, right) => left.id.localeCompare(right.id));
const diagnostics = sortedUnique([
@@ -219,7 +181,7 @@ export function buildPolicyEvaluation(input: EvaluationBuildInput): StoredPolicy
...results.flatMap(result => result.diagnosticCodes)
]);
const blocked = input.aggregation.run.status === 'blocked';
- const partial = blocked || input.aggregation.run.status !== 'complete' || results.some(result => result.classification === 'review_required');
+ const partial = blocked || results.some(result => result.classification === 'review_required');
const record: StoredPolicyEvaluation = {
version: 1,
run: {
@@ -316,4 +278,3 @@ export class GpoPolicyEvaluationService {
return structuredClone(this.ruleCatalog);
}
}
-
diff --git a/server/gpo/gpo-policy-finding-service.ts b/server/gpo/gpo-policy-finding-service.ts
index 5218dc3..dcacd7c 100644
--- a/server/gpo/gpo-policy-finding-service.ts
+++ b/server/gpo/gpo-policy-finding-service.ts
@@ -72,7 +72,7 @@ export function buildPolicyFindingRun(input: PolicyFindingBuildInput): StoredPol
for (const result of eligible) {
const codes = new Set(policyFindingCandidateInvariantCodes(input.evaluation, result));
- const state = states.get(result.aggregationStateId);
+ const state = result.aggregationStateId ? states.get(result.aggregationStateId) : undefined;
if (!state || state.identity.id !== result.identity.id) codes.add('policy-finding-aggregation-state-missing');
else {
if (state.status !== 'configured') codes.add('policy-finding-customer-state-not-configured');
@@ -105,7 +105,7 @@ export function buildPolicyFindingRun(input: PolicyFindingBuildInput): StoredPol
evaluationRunId: input.evaluation.run.id,
evaluationResultId: result.id,
aggregationRunId: input.aggregation.run.id,
- aggregationStateId: result.aggregationStateId,
+ aggregationStateId: result.aggregationStateId!,
snapshotId: input.aggregation.run.snapshotId,
environmentProfileId: input.profile.id,
environmentProfileRevision: input.profile.revision,
diff --git a/server/gpo/gpo-policy-snapshot-service.ts b/server/gpo/gpo-policy-snapshot-service.ts
index 753342a..58c5d89 100644
--- a/server/gpo/gpo-policy-snapshot-service.ts
+++ b/server/gpo/gpo-policy-snapshot-service.ts
@@ -79,6 +79,12 @@ function reduceBackupContribution(entries: ResolvedObservation[]): BackupContrib
}
const mechanism = observations[0].observation.deliveryMechanism;
+ if (mechanism === 'security-template' || mechanism === 'advanced-audit-policy') {
+ const values = valuesUnique(observations.flatMap(entry => entry.observation.values));
+ const complete = observations.every(entry => entry.observation.state === 'configured') && values.length === 1;
+ return { status: complete ? 'configured' : 'indeterminate', values, observationIds,
+ targeting: 'none', diagnosticCodes: [...diagnostics].sort() };
+ }
if (mechanism !== 'registry-policy') {
diagnostics.add('policy-aggregation-delivery-semantics-unsupported');
return {
@@ -411,4 +417,3 @@ export class GpoPolicySnapshotService {
return this.repository.listPolicySnapshotAggregations(projectId);
}
}
-
diff --git a/server/gpo/gpp-drive-maps.ts b/server/gpo/gpp-drive-maps.ts
index c07bf95..05f64c4 100644
--- a/server/gpo/gpp-drive-maps.ts
+++ b/server/gpo/gpp-drive-maps.ts
@@ -209,7 +209,7 @@ export function reduceDriveMapsPreferences(
if (document.status === 'invalid' || document.scope !== 'user') return [];
return document.instructions.map(instruction => {
const id = `gpo-policy-${createHash('sha256').update([
- context.backupInstanceId, document.sourceSha256, instruction.uid, String(instruction.sequence), GPP_DRIVE_MAPS_REDUCER.version
+ context.backupInstanceId, context.artifactId, document.sourceSha256, instruction.uid, String(instruction.sequence), GPP_DRIVE_MAPS_REDUCER.version
].join('\0')).digest('hex').slice(0, 32)}`;
const diagnostics = new Set();
if (instruction.targeting.status === 'present') diagnostics.add('gpo-preference-targeting-unevaluated');
diff --git a/server/gpo/gpp-local-users-groups.ts b/server/gpo/gpp-local-users-groups.ts
index 40a59c7..1b915cb 100644
--- a/server/gpo/gpp-local-users-groups.ts
+++ b/server/gpo/gpp-local-users-groups.ts
@@ -258,7 +258,7 @@ export function reduceLocalUsersGroupsPreferences(
? instruction.value.userName.toLocaleLowerCase('en-US')
: instruction.value.groupSid?.toLocaleUpperCase('en-US') ?? instruction.value.groupName.toLocaleLowerCase('en-US');
const id = `gpo-policy-${createHash('sha256').update([
- context.backupInstanceId, document.sourceSha256, instruction.uid, String(instruction.sequence), GPP_LOCAL_USERS_GROUPS_REDUCER.version
+ context.backupInstanceId, context.artifactId, document.sourceSha256, instruction.uid, String(instruction.sequence), GPP_LOCAL_USERS_GROUPS_REDUCER.version
].join('\0')).digest('hex').slice(0, 32)}`;
const diagnostics = new Set();
if (instruction.targeting.status === 'present') diagnostics.add('gpo-preference-targeting-unevaluated');
diff --git a/server/gpo/gpp-services.ts b/server/gpo/gpp-services.ts
index 49ea225..834bcaf 100644
--- a/server/gpo/gpp-services.ts
+++ b/server/gpo/gpp-services.ts
@@ -208,7 +208,7 @@ export function reduceServicesPreferences(
if (document.status === 'invalid' || document.scope !== 'computer') return [];
return document.instructions.map(instruction => {
const id = `gpo-policy-${createHash('sha256').update([
- context.backupInstanceId, document.sourceSha256, instruction.uid, String(instruction.sequence), GPP_SERVICES_REDUCER.version
+ context.backupInstanceId, context.artifactId, document.sourceSha256, instruction.uid, String(instruction.sequence), GPP_SERVICES_REDUCER.version
].join('\0')).digest('hex').slice(0, 32)}`;
const diagnostics = new Set();
if (instruction.targeting.status === 'present') diagnostics.add('gpo-preference-targeting-unevaluated');
diff --git a/server/gpo/group-policy-preference-parser.ts b/server/gpo/group-policy-preference-parser.ts
index a412827..ea335c1 100644
--- a/server/gpo/group-policy-preference-parser.ts
+++ b/server/gpo/group-policy-preference-parser.ts
@@ -320,7 +320,7 @@ export function reduceGroupPolicyPreferences(
};
const identityKey = [instruction.hive, instruction.key, instruction.target === 'key' ? '' : instruction.valueName ?? ''].join('\\');
const id = `gpo-policy-${createHash('sha256').update([
- context.backupInstanceId, document.sourceSha256, instruction.uid, String(instruction.sequence), GPP_REGISTRY_REDUCER.version
+ context.backupInstanceId, context.artifactId, document.sourceSha256, instruction.uid, String(instruction.sequence), GPP_REGISTRY_REDUCER.version
].join('\0')).digest('hex').slice(0, 32)}`;
const observation: GpoPolicyObservation = {
version: 1, id, backupInstanceId: context.backupInstanceId, sourceArtifactId: context.sourceArtifactId,
diff --git a/server/gpo/microsoft-security-baseline-parser.ts b/server/gpo/microsoft-security-baseline-parser.ts
index 6b23d1a..5a7314d 100644
--- a/server/gpo/microsoft-security-baseline-parser.ts
+++ b/server/gpo/microsoft-security-baseline-parser.ts
@@ -8,10 +8,13 @@ import {
} from '../../src/domain/microsoft-security-baseline-analysis';
import { aggregateGpoBackupMetadata } from '../../src/domain/gpo-metadata';
import { classifyGpoArtifactPath } from '../../src/gpo/artifact-classifier';
-import { buildAdmxPolicyCatalog, resolveRegistryPolicyIdentity } from './admx-policy-catalog';
+import { buildAdmxPolicyCatalog } from './admx-policy-catalog';
import { parseGpoBackupMetadataXml } from './gpo-metadata-parser';
import { readMicrosoftBaselineZip } from './microsoft-baseline-zip-reader';
import { parseRegistryPolicyFile, reduceRegistryPolicy } from './registry-policy-parser';
+import { parseSecurityTemplateInf, reduceSecurityTemplate } from './security-template-parser';
+import { parseAdvancedAuditCsv, reduceAdvancedAuditPolicy } from './advanced-audit-parser';
+import { resolvePolicyTarget } from './policy-target-resolver';
export interface MicrosoftSecurityBaselineAnalysisOptions {
baselineId: string;
@@ -37,7 +40,8 @@ function stableId(prefix: string, parts: string[]): string {
function selectedBaselineEntry(path: string): boolean {
return /(?:^|\/)Backup\.xml$/i.test(path)
|| /(?:^|\/)Registry\.pol$/i.test(path)
- || /\.(?:admx|adml)$/i.test(path);
+ || /\.(?:admx|adml)$/i.test(path)
+ || ['security-template', 'advanced-audit-policy'].includes(classifyGpoArtifactPath(path).role);
}
export function analyzeMicrosoftSecurityBaselinePackage(
@@ -61,10 +65,10 @@ export function analyzeMicrosoftSecurityBaselinePackage(
const metadataFiles = archive.files.filter(file => /(?:^|\/)Backup\.xml$/i.test(file.entry.relativePath));
const roots = metadataFiles.map(file => parentPath(file.entry.relativePath))
.filter(root => archive.entries.some(entry => entry.kind === 'file' && belongsToRoot(entry.relativePath, root)
- && classifyGpoArtifactPath(entry.relativePath).role === 'registry-policy'))
+ && ['registry-policy', 'security-template', 'advanced-audit-policy'].includes(classifyGpoArtifactPath(entry.relativePath).role)))
.sort((left, right) => right.length - left.length || left.localeCompare(right));
if (!roots.length) diagnostics.add('microsoft-baseline-registry-policy-missing');
- const selectedRegistryFiles = archive.files.filter(file => classifyGpoArtifactPath(file.entry.relativePath).role === 'registry-policy'
+ const selectedRegistryFiles = archive.files.filter(file => ['registry-policy', 'security-template', 'advanced-audit-policy'].includes(classifyGpoArtifactPath(file.entry.relativePath).role)
&& roots.some(root => belongsToRoot(file.entry.relativePath, root)));
const metadataByRoot = new Map[]>();
for (const file of metadataFiles) {
@@ -93,20 +97,27 @@ export function analyzeMicrosoftSecurityBaselinePackage(
const registryFiles = selectedRegistryFiles.filter(file => belongsToRoot(file.entry.relativePath, root));
for (const file of registryFiles) {
const classification = classifyGpoArtifactPath(file.entry.relativePath);
- const document = parseRegistryPolicyFile(file, classification.scope, options.resourcePolicy);
+ const context = { backupInstanceId: backupId, sourceArtifactId: options.baselineId,
+ artifactId: stableId('baseline-entry', [archive.containerSha256, file.entry.relativePath, file.entry.sha256]) };
+ const parsed = classification.role === 'security-template' ? (() => {
+ const document = parseSecurityTemplateInf(file, classification.scope, options.resourcePolicy);
+ return { document, observations: reduceSecurityTemplate(document, context) };
+ })() : classification.role === 'advanced-audit-policy' ? (() => {
+ const document = parseAdvancedAuditCsv(file, classification.scope, options.resourcePolicy);
+ return { document, observations: reduceAdvancedAuditPolicy(document, context) };
+ })() : (() => {
+ const document = parseRegistryPolicyFile(file, classification.scope, options.resourcePolicy);
+ return { document, observations: reduceRegistryPolicy(document, context) };
+ })();
+ const { document, observations } = parsed;
document.diagnosticCodes.forEach(code => diagnostics.add(code));
if (document.status !== 'complete') partial = true;
- const observations = reduceRegistryPolicy(document, {
- backupInstanceId: backupId,
- sourceArtifactId: options.baselineId,
- artifactId: stableId('baseline-entry', [archive.containerSha256, file.entry.relativePath, file.entry.sha256])
- });
for (const observation of observations) {
- const identity = resolveRegistryPolicyIdentity(observation, admxCatalog);
+ const identity = resolvePolicyTarget(observation, admxCatalog);
if (identity.status !== 'resolved') {
diagnostics.add('microsoft-baseline-policy-identity-unresolved');
partial = true;
- } else if (identity.identity.admx.status !== 'matched') {
+ } else if (observation.deliveryMechanism === 'registry-policy' && identity.identity.admx.status !== 'matched') {
diagnostics.add(identity.identity.admx.status === 'ambiguous'
? 'microsoft-baseline-admx-identity-ambiguous'
: 'microsoft-baseline-admx-metadata-not-found');
@@ -116,7 +127,7 @@ export function analyzeMicrosoftSecurityBaselinePackage(
version: 1,
id: stableId('microsoft-baseline-setting', [
options.baselineId, backupId, observation.sourceSha256,
- observation.registryPolicy?.sequence.toString() ?? '', MICROSOFT_BASELINE_SETTINGS_ANALYZER.version
+ observation.id, MICROSOFT_BASELINE_SETTINGS_ANALYZER.version
]),
baselineId: options.baselineId,
backupId,
@@ -131,6 +142,7 @@ export function analyzeMicrosoftSecurityBaselinePackage(
values: observation.values,
registryPolicy: observation.registryPolicy,
sourceRecords: observation.sourceRecords,
+ sourceLines: observation.sourceLines,
effectiveState: observation.effectiveState,
diagnosticCodes: observation.diagnosticCodes
},
@@ -150,7 +162,7 @@ export function analyzeMicrosoftSecurityBaselinePackage(
status: partial ? 'partial' : 'complete',
admxCatalog,
backupCount: new Set(roots).size,
- registryPolicyFileCount: selectedRegistryFiles.length,
+ registryPolicyFileCount: selectedRegistryFiles.filter(file => classifyGpoArtifactPath(file.entry.relativePath).role === 'registry-policy').length,
settings: settings.sort((left, right) => left.id.localeCompare(right.id)),
diagnosticCodes: [...diagnostics].sort()
};
diff --git a/server/gpo/policy-target-resolver.ts b/server/gpo/policy-target-resolver.ts
new file mode 100644
index 0000000..0e9715a
--- /dev/null
+++ b/server/gpo/policy-target-resolver.ts
@@ -0,0 +1,24 @@
+import { createHash } from 'node:crypto';
+import { GPO_NATIVE_POLICY_IDENTITY_RESOLVER, gpoTechnicalPolicyIdentityValidationErrors,
+ type AdmxPolicyCatalog, type GpoPolicyIdentityResolution } from '../../src/domain/gpo-policy-identity';
+import type { GpoPolicyObservation } from '../../src/domain/gpo-policy';
+import { resolveRegistryPolicyIdentity } from './admx-policy-catalog';
+
+export function resolvePolicyTarget(observation: GpoPolicyObservation, catalog?: AdmxPolicyCatalog): GpoPolicyIdentityResolution {
+ if (observation.deliveryMechanism === 'registry-policy') return resolveRegistryPolicyIdentity(observation, catalog);
+ if (!['security-template', 'advanced-audit-policy'].includes(observation.deliveryMechanism)) {
+ return { version: 1, status: 'unresolved', reasonCode: `identity-resolver-unsupported-${observation.deliveryMechanism}` };
+ }
+ const kind = observation.deliveryMechanism as 'security-template' | 'advanced-audit-policy';
+ const section = observation.identity.section.normalize('NFC').toLowerCase();
+ const key = observation.identity.key.normalize('NFC').toLowerCase();
+ const digest = createHash('sha256').update(['native-policy-target-v1', kind, observation.scope, section, key].join('\0')).digest('hex');
+ const identity = {
+ version: 1 as const, id: `gpo-policy-identity-${digest.slice(0, 32)}`, resolver: GPO_NATIVE_POLICY_IDENTITY_RESOLVER,
+ scope: observation.scope, target: { kind, section, key }, admx: { status: 'not-found' as const }
+ };
+ if (gpoTechnicalPolicyIdentityValidationErrors(identity).length) {
+ return { version: 1, status: 'unresolved', reasonCode: 'policy-technical-target-invalid' };
+ }
+ return { version: 1, status: 'resolved', identity };
+}
diff --git a/server/gpo/registry-policy-parser.ts b/server/gpo/registry-policy-parser.ts
index 89666bf..64db20f 100644
--- a/server/gpo/registry-policy-parser.ts
+++ b/server/gpo/registry-policy-parser.ts
@@ -324,6 +324,7 @@ export function reduceRegistryPolicy(
const target = interpreted.value.valueName ?? interpreted.value.targets?.join(';') ?? interpreted.value.operation;
const id = 'gpo-policy-' + createHash('sha256').update([
context.backupInstanceId,
+ context.artifactId,
document.sourceSha256,
instruction.sequence.toString(),
REGISTRY_POLICY_REDUCER.version
@@ -357,4 +358,4 @@ export function reduceRegistryPolicy(
if (errors.length) throw new Error('Intern ungültige Registry-Policy-Beobachtung: ' + errors.join(' '));
return observation;
});
-}
\ No newline at end of file
+}
diff --git a/server/gpo/security-template-parser.ts b/server/gpo/security-template-parser.ts
index 821e030..3103174 100644
--- a/server/gpo/security-template-parser.ts
+++ b/server/gpo/security-template-parser.ts
@@ -158,6 +158,7 @@ export function reduceSecurityTemplate(
const conflicted = distinctValues.length > 1;
const id = `gpo-policy-${createHash('sha256').update([
context.backupInstanceId,
+ context.artifactId,
document.sourceSha256,
first.section,
first.key.toLocaleLowerCase('en-US'),
diff --git a/server/index.ts b/server/index.ts
index 0d9d2da..e12d1b9 100644
--- a/server/index.ts
+++ b/server/index.ts
@@ -10,6 +10,7 @@ import { GpoBackupJobProcessor, GpoBackupJobRunner } from './gpo/gpo-backup-job-
import { GpoArtifactReconciler, GpoArtifactReconciliationRunner } from './gpo/gpo-artifact-reconciler';
import { GpoBackupManagementService } from './gpo/gpo-backup-management-service';
import { NodeGpoInventoryWorkerExecutor } from './gpo/gpo-inventory-worker-client';
+import { GpoAutomaticAnalysisService } from './gpo/gpo-automatic-analysis-service';
import { MicrosoftSecurityBaselineService } from './gpo/microsoft-security-baseline-service';
import { GpoPolicySnapshotService } from './gpo/gpo-policy-snapshot-service';
import { GpoPolicyEvaluationService } from './gpo/gpo-policy-evaluation-service';
@@ -79,11 +80,14 @@ async function main(): Promise {
apiKey: process.env.NVD_API_KEY?.trim() || undefined,
timeoutMs: boundedInteger(process.env.ASSESSOR_NVD_TIMEOUT_MS, 15_000, 1_000, 60_000, 'ASSESSOR_NVD_TIMEOUT_MS')
}));
+ const automaticGpoAnalysis = new GpoAutomaticAnalysisService(runtime.repository,
+ gpoPolicySnapshotService, gpoPolicyEvaluationService, gpoPolicyFindingService);
await microsoftSecurityBaselineService.refreshDetectedMetadata();
const baselineBackfill = await microsoftSecurityBaselineService.reprocessPending();
if (baselineBackfill.failed) console.warn('Microsoft-Baseline-Backfill:', baselineBackfill.analyzed,
'analysiert,', baselineBackfill.failed, 'fehlgeschlagen.');
const gpoJobProcessor = new GpoBackupJobProcessor(runtime.repository, artifactStore, gpoInventoryExecutor, {
+ afterAnalysis: (projectId, runId) => automaticGpoAnalysis.run(projectId, runId),
maximumArtifactBytes: defaultImportResourcePolicy.maximumFileBytes,
leaseDurationMs: boundedInteger(process.env.ASSESSOR_GPO_JOB_LEASE_MS, 60_000, 1_000, 3_600_000, 'ASSESSOR_GPO_JOB_LEASE_MS'),
retryDelayMs: boundedInteger(process.env.ASSESSOR_GPO_JOB_RETRY_MS, 5_000, 0, 300_000, 'ASSESSOR_GPO_JOB_RETRY_MS')
@@ -115,6 +119,7 @@ async function main(): Promise {
gpoPolicyFindingService,
gpoPolicyAnalysisOverviewService,
cveEnrichmentService,
+ automaticGpoAnalysis,
importExecutor
});
server.listen(parsedPort, host, () => {
diff --git a/server/postgres/migration-catalog.ts b/server/postgres/migration-catalog.ts
index 8804acf..1beebc2 100644
--- a/server/postgres/migration-catalog.ts
+++ b/server/postgres/migration-catalog.ts
@@ -19,6 +19,8 @@ import scannerEnvironmentContext from './migrations/018_scanner_environment_cont
import cveEnrichment from './migrations/021_cve_enrichment.sql?raw';
import vulnerabilityFindingResultType from './migrations/022_vulnerability_finding_result_type.sql?raw';
import defenderVulnerabilityBackfill from './migrations/023_defender_vulnerability_backfill.sql?raw';
+import nativePolicyTargets from './migrations/019_native_policy_targets.sql?raw';
+import baselineDrivenPolicyEvaluation from './migrations/020_baseline_driven_policy_evaluation.sql?raw';
export interface DatabaseMigration {
version: string;
@@ -45,6 +47,8 @@ export const databaseMigrations: readonly DatabaseMigration[] = [
{ version: '016', name: 'policy-evaluation-rule-catalogs', sql: policyEvaluationRuleCatalogs },
{ version: '017', name: 'policy-finding-factory', sql: policyFindingFactory },
{ version: '018', name: 'scanner-environment-context', sql: scannerEnvironmentContext },
+ { version: '019', name: 'native-policy-targets', sql: nativePolicyTargets },
+ { version: '020', name: 'baseline-driven-policy-evaluation', sql: baselineDrivenPolicyEvaluation },
{ version: '021', name: 'cve-enrichment', sql: cveEnrichment },
{ version: '022', name: 'vulnerability-finding-result-type', sql: vulnerabilityFindingResultType },
{ version: '023', name: 'defender-vulnerability-backfill', sql: defenderVulnerabilityBackfill }
diff --git a/server/postgres/migrations/019_native_policy_targets.sql b/server/postgres/migrations/019_native_policy_targets.sql
new file mode 100644
index 0000000..78eb77f
--- /dev/null
+++ b/server/postgres/migrations/019_native_policy_targets.sql
@@ -0,0 +1,6 @@
+-- Additive targets; existing Registry identities and original evidence remain unchanged.
+ALTER TABLE assessor_policy_identities
+ DROP CONSTRAINT assessor_policy_identities_target_kind_check;
+ALTER TABLE assessor_policy_identities
+ ADD CONSTRAINT assessor_policy_identities_target_kind_check
+ CHECK (target_kind IN ('registry-key', 'registry-value', 'security-template', 'advanced-audit-policy'));
diff --git a/server/postgres/migrations/020_baseline_driven_policy_evaluation.sql b/server/postgres/migrations/020_baseline_driven_policy_evaluation.sql
new file mode 100644
index 0000000..9b8cb63
--- /dev/null
+++ b/server/postgres/migrations/020_baseline_driven_policy_evaluation.sql
@@ -0,0 +1,30 @@
+ALTER TABLE assessor_policy_evaluation_results
+ ALTER COLUMN aggregation_state_id DROP NOT NULL,
+ ADD COLUMN baseline_analysis_id text REFERENCES assessor_microsoft_security_baseline_analyses(id) ON DELETE RESTRICT,
+ ADD COLUMN customer_state text NOT NULL DEFAULT 'configured'
+ CONSTRAINT assessor_policy_evaluation_results_customer_state_value_check
+ CHECK (customer_state IN ('configured', 'missing', 'conflicted', 'indeterminate')),
+ ADD CONSTRAINT assessor_policy_evaluation_results_customer_state_check CHECK (
+ (customer_state = 'missing' AND aggregation_state_id IS NULL)
+ OR (customer_state <> 'missing' AND aggregation_state_id IS NOT NULL)
+ );
+
+DO $$
+DECLARE constraint_name text;
+BEGIN
+ SELECT con.conname INTO constraint_name
+ FROM pg_constraint con
+ WHERE con.conrelid = 'assessor_policy_evaluation_results'::regclass
+ AND con.contype = 'u'
+ AND pg_get_constraintdef(con.oid) = 'UNIQUE (evaluation_run_id, aggregation_state_id)';
+ IF constraint_name IS NOT NULL THEN
+ EXECUTE format('ALTER TABLE assessor_policy_evaluation_results DROP CONSTRAINT %I', constraint_name);
+ END IF;
+END $$;
+
+CREATE UNIQUE INDEX assessor_policy_evaluation_results_baseline_identity_uq
+ ON assessor_policy_evaluation_results(evaluation_run_id, baseline_analysis_id, identity_id)
+ WHERE baseline_analysis_id IS NOT NULL;
+
+CREATE INDEX assessor_policy_evaluation_results_baseline_idx
+ ON assessor_policy_evaluation_results(baseline_analysis_id, classification, id);
diff --git a/server/postgres/postgres-assessor-repository.ts b/server/postgres/postgres-assessor-repository.ts
index 892fc72..ce53a24 100644
--- a/server/postgres/postgres-assessor-repository.ts
+++ b/server/postgres/postgres-assessor-repository.ts
@@ -19,8 +19,8 @@ import type { StoredGpoBackupInstance, StoredGpoPolicyAnalysis } from '../../src
import type { MicrosoftSecurityBaselineClassification, MicrosoftSecurityBaselineRecord } from '../../src/domain/microsoft-security-baseline';
import type { StoredMicrosoftSecurityBaselineAnalysis } from '../../src/domain/microsoft-security-baseline-analysis';
import type { EnvironmentProfile, StoredPolicySnapshotAggregation } from '../../src/domain/gpo-snapshot-aggregation';
-import type { StoredPolicyEvaluation } from '../../src/domain/policy-evaluation';
-import { storedPolicyEvaluationValidationErrors } from '../../src/domain/policy-evaluation';
+import type { PolicyEvaluationResult, PolicyEvaluationRun, StoredPolicyEvaluation } from '../../src/domain/policy-evaluation';
+import { POLICY_EVALUATION_ENGINE, storedPolicyEvaluationValidationErrors } from '../../src/domain/policy-evaluation';
import type { StoredPolicyFindingRun } from '../../src/domain/policy-finding';
import type { EnvironmentObservation, EnvironmentSnapshot, EnvironmentSnapshotQuery, ScannerReportSection } from '../../src/domain/environment-context';
import { environmentCoverage } from '../../src/domain/environment-context';
@@ -36,6 +36,7 @@ import type { DbStructureColumn, DbStructureForeignKey, DbStructureLayerId, DbSt
import { storedGpoBackupInstanceValidationErrors, storedGpoPolicyAnalysisValidationErrors } from '../../src/domain/gpo-analysis-persistence';
import {
createEnvironmentUnifiedResult,
+ createPolicyEvaluationUnifiedResult,
createCurrentPolicyObservationUnifiedResults,
createPolicyUnifiedResult,
createScannerUnifiedResult,
@@ -1040,10 +1041,13 @@ export class PostgresAssessorRepository implements AssessorRepository {
WHERE ${conditions.join(' AND ')}
ORDER BY o.scan_run_id, o.property_key, o.id
`, values);
- return result.rows.map(row => createEnvironmentUnifiedResult({
- project: clone(row.project), assessment: clone(row.assessment), scanRun: clone(row.scan_run),
- importFile: clone(row.import_file), observation: clone(row.observation)
- }));
+ return result.rows.flatMap(row => {
+ const projection = createEnvironmentUnifiedResult({
+ project: clone(row.project), assessment: clone(row.assessment), scanRun: clone(row.scan_run),
+ importFile: clone(row.import_file), observation: clone(row.observation)
+ });
+ return projection ? [projection] : [];
+ });
}
private async unifiedPolicyResults(
@@ -1064,17 +1068,90 @@ export class PostgresAssessorRepository implements AssessorRepository {
const result = await this.pool.query<{
definition: FindingDefinition;
occurrence: StoredPolicyFindingRun['occurrences'][number];
+ comparison: PolicyEvaluationResult | null;
} & QueryResultRow>(`
- SELECT d.data AS definition, o.data AS occurrence
+ SELECT d.data AS definition, o.data AS occurrence, comparison.data AS comparison
FROM assessor_policy_finding_occurrences o
JOIN assessor_policy_finding_runs r ON r.id = o.factory_run_id
JOIN assessor_finding_definitions d ON d.id = o.definition_id
+ LEFT JOIN assessor_policy_evaluation_results comparison ON comparison.id = o.evaluation_result_id
+ AND comparison.evaluation_run_id = r.evaluation_run_id
${where}
ORDER BY r.completed_at, o.id
`, values);
return result.rows.map(row => createPolicyUnifiedResult({
definition: clone(row.definition),
- occurrence: clone(row.occurrence)
+ occurrence: clone(row.occurrence),
+ comparison: row.comparison ? clone(row.comparison) : undefined
+ }));
+ }
+
+ private async unifiedPolicyEvaluationComparisonResults(
+ query: UnifiedResultQuery = {},
+ evaluationResultId?: string
+ ): Promise {
+ if (query.sourceKind?.length && !query.sourceKind.includes('policy-evaluation')) return [];
+ const values: unknown[] = [POLICY_EVALUATION_ENGINE.version];
+ const conditions = ['finding.id IS NULL'];
+ const add = (expression: string, value: unknown) => {
+ values.push(value);
+ conditions.push(expression.replace('?', `$${values.length}`));
+ };
+ if (query.projectId) add('selected.project_id = ?', query.projectId);
+ if (query.evaluationRunId) add('selected.id = ?', query.evaluationRunId);
+ if (evaluationResultId) add('result.id = ?', evaluationResultId);
+ const rows = await this.pool.query<{
+ run: PolicyEvaluationRun;
+ result: PolicyEvaluationResult;
+ snapshot_id: string;
+ assessment_ids: string[];
+ artifact_ids: string[];
+ } & QueryResultRow>(`
+ WITH ranked AS (
+ SELECT evaluation.*,
+ row_number() OVER (
+ PARTITION BY evaluation.aggregation_run_id
+ ORDER BY jsonb_array_length(evaluation.data->'run'->'baselineAnalysisIds') DESC,
+ evaluation.completed_at DESC, evaluation.id DESC
+ ) AS run_rank
+ FROM assessor_policy_evaluation_runs evaluation
+ WHERE evaluation.evaluator_version = $1
+ AND NOT EXISTS (
+ SELECT 1
+ FROM assessor_policy_snapshot_aggregation_sources source
+ JOIN assessor_policy_identity_analysis_runs newer
+ ON newer.supersedes_analysis_run_id = source.analysis_run_id
+ WHERE source.aggregation_run_id = evaluation.aggregation_run_id
+ )
+ ), selected AS MATERIALIZED (
+ SELECT id, project_id, aggregation_run_id, completed_at, data->'run' AS run
+ FROM ranked
+ WHERE run_rank = 1
+ ), aggregation_context AS MATERIALIZED (
+ SELECT source.aggregation_run_id,
+ array_agg(DISTINCT artifact.assessment_id) FILTER (WHERE artifact.assessment_id IS NOT NULL) AS assessment_ids,
+ array_agg(DISTINCT artifact.id) AS artifact_ids
+ FROM assessor_policy_snapshot_aggregation_sources source
+ JOIN assessor_policy_identity_analysis_runs analysis ON analysis.id = source.analysis_run_id
+ JOIN assessor_import_artifacts artifact ON artifact.id = analysis.artifact_id
+ GROUP BY source.aggregation_run_id
+ )
+ SELECT selected.run, result.data AS result,
+ aggregation.snapshot_id,
+ coalesce(context.assessment_ids, ARRAY[]::text[]) AS assessment_ids,
+ coalesce(context.artifact_ids, ARRAY[]::text[]) AS artifact_ids
+ FROM selected
+ JOIN assessor_policy_evaluation_results result ON result.evaluation_run_id = selected.id
+ JOIN assessor_policy_snapshot_aggregation_runs aggregation ON aggregation.id = selected.aggregation_run_id
+ LEFT JOIN aggregation_context context ON context.aggregation_run_id = selected.aggregation_run_id
+ LEFT JOIN assessor_policy_finding_occurrences finding ON finding.evaluation_result_id = result.id
+ WHERE ${conditions.join(' AND ')}
+ ORDER BY selected.completed_at, result.id
+ `, values);
+ return rows.rows.map(row => createPolicyEvaluationUnifiedResult(row.run, row.result, {
+ assessmentId: row.assessment_ids.length === 1 ? row.assessment_ids[0] : undefined,
+ importArtifactId: row.artifact_ids.length === 1 ? row.artifact_ids[0] : undefined,
+ snapshotId: row.snapshot_id
}));
}
@@ -1082,6 +1159,7 @@ export class PostgresAssessorRepository implements AssessorRepository {
query: UnifiedResultQuery = {},
observationId?: string
): Promise {
+ if (query.audience !== 'internal-analysis') return [];
if (query.sourceKind?.length && !query.sourceKind.includes('policy-observation')) return [];
const where = query.projectId ? 'WHERE project_id = $1' : '';
const values = query.projectId ? [query.projectId] : [];
@@ -1101,13 +1179,14 @@ export class PostgresAssessorRepository implements AssessorRepository {
}
private async allUnifiedResults(query: UnifiedResultQuery = {}): Promise {
- const [scanner, environment, policyObservations, policy] = await Promise.all([
+ const [scanner, environment, policyObservations, policyEvaluations, policy] = await Promise.all([
this.unifiedScannerResults(query),
this.unifiedEnvironmentResults(query),
this.unifiedPolicyObservationResults(query),
+ this.unifiedPolicyEvaluationComparisonResults(query),
this.unifiedPolicyResults(query)
]);
- return [...scanner, ...environment, ...policyObservations, ...policy];
+ return [...scanner, ...environment, ...policyObservations, ...policyEvaluations, ...policy];
}
async queryUnifiedResults(query: UnifiedResultQuery = {}): Promise {
@@ -1121,10 +1200,13 @@ export class PostgresAssessorRepository implements AssessorRepository {
async getUnifiedResultById(resultProjectionId: string): Promise {
const scannerPrefix = 'scanner-finding:';
const policyPrefix = 'policy-evaluation:';
+ const policyComparisonPrefix = 'policy-evaluation-comparison:';
const policyObservationPrefix = 'policy-observation:';
const environmentPrefix = 'environment-observation:';
const items = resultProjectionId.startsWith(scannerPrefix)
? await this.unifiedScannerResults({}, resultProjectionId.slice(scannerPrefix.length))
+ : resultProjectionId.startsWith(policyComparisonPrefix)
+ ? await this.unifiedPolicyEvaluationComparisonResults({}, resultProjectionId.slice(policyComparisonPrefix.length))
: resultProjectionId.startsWith(policyPrefix)
? await this.unifiedPolicyResults({}, resultProjectionId.slice(policyPrefix.length))
: resultProjectionId.startsWith(policyObservationPrefix)
@@ -1620,7 +1702,9 @@ export class PostgresAssessorRepository implements AssessorRepository {
[record.run.aggregationRunId]
);
const stateIdentity = new Map(states.rows.map(row => [row.id, row.identity_id]));
- if (record.results.some(result => stateIdentity.get(result.aggregationStateId) !== result.identity.id)) {
+ if (record.results.some(result => result.aggregationStateId
+ ? stateIdentity.get(result.aggregationStateId) !== result.identity.id
+ : result.customerState !== 'missing')) {
throw new RepositoryValidationError('Ein Evaluationsergebnis verweist auf einen fremden Aggregationszustand.');
}
await client.query(
@@ -1640,8 +1724,9 @@ export class PostgresAssessorRepository implements AssessorRepository {
}
for (const result of record.results) {
await client.query(
- 'INSERT INTO assessor_policy_evaluation_results (id, evaluation_run_id, aggregation_state_id, identity_id, classification, baseline_state, comparator_kind, rule_ids, dependency_rule_ids, risk_rule_ids, finding_eligible, effective_state, data) VALUES ($1, $2, $3, $4, $5, $6, $7, $8::text[], $9::text[], $10::text[], $11, $12, $13::jsonb)',
- [result.id, record.run.id, result.aggregationStateId, result.identity.id, result.classification,
+ 'INSERT INTO assessor_policy_evaluation_results (id, evaluation_run_id, aggregation_state_id, baseline_analysis_id, customer_state, identity_id, classification, baseline_state, comparator_kind, rule_ids, dependency_rule_ids, risk_rule_ids, finding_eligible, effective_state, data) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10::text[], $11::text[], $12::text[], $13, $14, $15::jsonb)',
+ [result.id, record.run.id, result.aggregationStateId ?? null, result.baselineAnalysisId, result.customerState,
+ result.identity.id, result.classification,
result.baselineState, result.comparator.comparator.kind, result.ruleIds, result.dependencyRuleIds,
result.riskRuleIds, result.findingEligibility === 'eligible', result.effectiveState, json(result)]
);
@@ -1758,15 +1843,16 @@ export class PostgresAssessorRepository implements AssessorRepository {
'SELECT data FROM assessor_microsoft_security_baselines WHERE id = $1 FOR UPDATE', [baselineId]
));
if (!record) return null;
- const referenced = await client.query(`
- SELECT 1
- FROM assessor_policy_evaluation_baseline_sources
- WHERE baseline_id = $1
- LIMIT 1
+ // Evaluations and findings are reproducible derivatives. Explicit baseline deletion
+ // removes only chains that consume this baseline; customer snapshots and imports remain.
+ await client.query(`
+ DELETE FROM assessor_policy_evaluation_runs
+ WHERE id IN (
+ SELECT evaluation_run_id
+ FROM assessor_policy_evaluation_baseline_sources
+ WHERE baseline_id = $1
+ )
`, [baselineId]);
- if (referenced.rowCount) {
- throw new RepositoryConflictError('The Microsoft baseline is referenced by a policy evaluation and cannot be deleted.');
- }
await client.query('UPDATE assessor_microsoft_security_baseline_classifications SET supersedes_classification_id = NULL WHERE baseline_id = $1', [baselineId]);
await client.query('UPDATE assessor_microsoft_security_baseline_analyses SET supersedes_analysis_id = NULL WHERE baseline_id = $1', [baselineId]);
await client.query('DELETE FROM assessor_microsoft_security_baselines WHERE id = $1', [baselineId]);
@@ -1903,17 +1989,19 @@ export class PostgresAssessorRepository implements AssessorRepository {
'status', 'dead-letter', 'lastErrorCode', coalesce(data->>'lastErrorCode', 'lease-expired'), 'updatedAt', $1::text
)
WHERE job_status = 'running' AND attempts >= max_attempts AND lease_expires_at <= $1
- `, [claim.now]);
+ AND ($2::text IS NULL OR project_id = $2)
+ `, [claim.now, claim.projectId ?? null]);
const selected = await client.query>(`
SELECT data FROM assessor_ingestion_jobs
WHERE attempts < max_attempts
AND ($2::text[] IS NULL OR job_kind = ANY($2::text[]))
+ AND ($3::text IS NULL OR project_id = $3)
AND ((job_status = 'queued' AND available_at <= $1)
OR (job_status = 'running' AND lease_expires_at <= $1))
ORDER BY available_at, created_at, id
FOR UPDATE SKIP LOCKED
LIMIT 1
- `, [claim.now, claim.kinds?.length ? claim.kinds : null]);
+ `, [claim.now, claim.kinds?.length ? claim.kinds : null, claim.projectId ?? null]);
const current = selected.rows[0]?.data;
if (!current) return { job: null, cleaned: Boolean(exhausted.rowCount) };
const updated: IngestionJob = {
@@ -1997,19 +2085,19 @@ export class PostgresAssessorRepository implements AssessorRepository {
});
}
- async deleteFailedGpoArtifact(projectId: string, artifactId: string, request: ArtifactDeletionRequest) {
+ async deleteGpoArtifact(projectId: string, artifactId: string, request: ArtifactDeletionRequest) {
return this.mutate(async client => {
const selected = await client.query>(
'SELECT data FROM assessor_import_artifacts WHERE id = $1 AND project_id = $2 FOR UPDATE', [artifactId, projectId]
);
const artifact = selected.rows[0]?.data;
if (!artifact || artifact.storage.kind !== 'backend-controlled' || artifact.kind !== 'source-file' || !artifact.relativePath.startsWith('gpo-backups/')) {
- throw new RepositoryNotFoundError('Das fehlgeschlagene GPO-Artefakt ist im Mandanten nicht vorhanden.');
+ throw new RepositoryNotFoundError('Das GPO-Artefakt ist im Mandanten nicht vorhanden.');
}
const jobs = dataRows(await client.query>(
`SELECT data FROM assessor_ingestion_jobs WHERE artifact_id = $1 AND project_id = $2 AND job_kind = 'analyze-gpo-backup' FOR UPDATE`, [artifactId, projectId]
));
- if (!jobs.length || jobs.some(item => item.status !== 'dead-letter')) throw new RepositoryConflictError('Nur ein endgültig fehlgeschlagener GPO-Import kann gelöscht werden.');
+ if (jobs.some(item => item.status === 'queued' || item.status === 'running')) throw new RepositoryConflictError('Ein laufender GPO-Import kann nicht gelöscht werden.');
if (request.version !== 1 || request.projectId !== projectId || request.artifactId !== artifactId
|| request.storageKey !== artifact.storage.storageKey || request.attempts !== 0
|| !request.id.trim() || !Number.isFinite(Date.parse(request.createdAt)) || !Number.isFinite(Date.parse(request.nextAttemptAt))) {
@@ -2026,7 +2114,31 @@ export class PostgresAssessorRepository implements AssessorRepository {
'SELECT data FROM assessor_artifact_deletion_outbox WHERE storage_key = $1 FOR UPDATE', [request.storageKey]
)).rows[0]?.data;
if (!storedRequest || storedRequest.artifactId !== artifactId || storedRequest.projectId !== projectId) throw new RepositoryConflictError('Speicherobjekt besitzt einen abweichenden Löschauftrag.');
+ await client.query(`
+ DELETE FROM assessor_policy_snapshot_aggregation_runs aggregation
+ WHERE EXISTS (
+ SELECT 1
+ FROM assessor_policy_snapshot_aggregation_sources source
+ JOIN assessor_policy_identity_analysis_runs analysis ON analysis.id = source.analysis_run_id
+ WHERE source.aggregation_run_id = aggregation.id
+ AND analysis.project_id = $1
+ AND analysis.artifact_id = $2
+ )
+ `, [projectId, artifactId]);
+ await client.query(
+ 'UPDATE assessor_policy_identity_analysis_runs SET supersedes_analysis_run_id = NULL WHERE project_id = $1 AND artifact_id = $2',
+ [projectId, artifactId]
+ );
+ await client.query(
+ 'UPDATE assessor_import_processing_runs SET supersedes_run_id = NULL WHERE project_id = $1 AND artifact_id = $2',
+ [projectId, artifactId]
+ );
await client.query('DELETE FROM assessor_import_artifacts WHERE id = $1 AND project_id = $2', [artifactId, projectId]);
+ await client.query(`
+ DELETE FROM assessor_finding_definitions definition
+ WHERE NOT EXISTS (SELECT 1 FROM assessor_finding_occurrences occurrence WHERE occurrence.definition_id = definition.id)
+ AND NOT EXISTS (SELECT 1 FROM assessor_policy_finding_occurrences occurrence WHERE occurrence.definition_id = definition.id)
+ `);
return { artifact: clone(artifact), request: clone(storedRequest) };
});
}
diff --git a/src/api/assessor-api-client.ts b/src/api/assessor-api-client.ts
index 44c0e61..7395486 100644
--- a/src/api/assessor-api-client.ts
+++ b/src/api/assessor-api-client.ts
@@ -1,4 +1,4 @@
-import type { Assessment, AssessmentProject, CanonicalAssessmentModel, ImportFileRecord } from '../domain/canonical-model';
+import type { Assessment, AssessmentProject, CanonicalAssessmentModel, FindingReview, ImportFileRecord } from '../domain/canonical-model';
import type {
UnifiedResultCategory,
UnifiedResultFacetResult,
@@ -168,6 +168,14 @@ export class AssessorApiClient {
return this.request(`/assessments/${encodeURIComponent(assessmentId)}/model`);
}
+ listProjectReviews(projectId: string): Promise {
+ return this.request(`/projects/${encodeURIComponent(projectId)}/reviews`);
+ }
+
+ saveReview(review: FindingReview, expectedRevision?: number): Promise<{ review: FindingReview; repositoryRevision: number }> {
+ return this.request('/reviews', { method: 'POST', body: JSON.stringify({ review, expectedRevision }) });
+ }
+
queryUnifiedResults(query: UnifiedResultQuery = {}): Promise {
return this.request(unifiedQueryPath('/results', query));
}
@@ -220,6 +228,12 @@ export class AssessorApiClient {
});
}
+ evaluateGpoBackup(projectId: string, artifactId: string): Promise<{ state: 'context-required' | 'baseline-required' | 'review' | 'evaluated' }> {
+ return this.request(`/projects/${encodeURIComponent(projectId)}/gpo-backups/${encodeURIComponent(artifactId)}/evaluate`, {
+ method: 'POST', body: JSON.stringify({})
+ });
+ }
+
async submitGpoBackup(projectId: string, file: File, assessmentId?: string): Promise {
const bytes = new Uint8Array(await file.arrayBuffer());
return this.request(`/projects/${encodeURIComponent(projectId)}/gpo-backups`, {
@@ -301,7 +315,7 @@ export class AssessorApiClient {
return this.request('/projects/' + encodeURIComponent(projectId) + '/policy-analysis-overview');
}
- deleteFailedGpoBackup(projectId: string, artifactId: string): Promise {
+ deleteGpoBackup(projectId: string, artifactId: string): Promise {
return this.request(`/projects/${encodeURIComponent(projectId)}/gpo-backups/${encodeURIComponent(artifactId)}`, {
method: 'DELETE', body: JSON.stringify({ artifactId, confirmDelete: true })
});
diff --git a/src/api/assessor-api-contract.ts b/src/api/assessor-api-contract.ts
index 19ef735..f70e782 100644
--- a/src/api/assessor-api-contract.ts
+++ b/src/api/assessor-api-contract.ts
@@ -21,6 +21,7 @@ export const ASSESSOR_MUTATION_HEADER = 'X-Assessor-Request';
export interface AssessorHealthResponse {
status: 'ok';
application: 'ASSESSOR';
+ productVersion: string;
apiVersion: 1;
releaseId?: string;
developmentInstanceId?: string;
diff --git a/src/app/App.tsx b/src/app/App.tsx
index 5de5947..8eb19ac 100644
--- a/src/app/App.tsx
+++ b/src/app/App.tsx
@@ -16,14 +16,15 @@ import { rowsToSpreadsheetSafeCsv } from '../exports/csv-export';
import { downloadText } from '../exports/text-download';
import { exportSnapshot } from '../exports/snapshot-export';
import { browserDownloadAdapter } from '../platform/browser/browser-download-adapter';
-import assessorDarkLogo from '../assets/branding/assessor-icon-dark-128.png';
-import assessorLightLogo from '../assets/branding/assessor-icon-light-128.png';
+import assessorLogo from '../assets/branding/assessor-icon-transparent.png';
import { TriangleIcon } from '../components/TriangleIcon';
import { SidebarSeverityMetrics } from '../features/sidebar/SidebarSeverityMetrics';
import { ViewBookmarks } from '../features/view-bookmarks/ViewBookmarks';
import { pathSnapshotFindingIds, type PathSnapshotState, type ViewBookmark } from '../features/view-bookmarks/view-bookmarks';
import { PathfinderFilterTrail } from '../features/mitre-graph/PathfinderFilterTrail';
-import { CURRENT_ASSESSOR_PROCESSING_VERSION } from '../domain/processing-compatibility';
+import { ASSESSOR_PRODUCT_VERSION } from '../domain/assessor-release';
+import { hasSelectedTimeslotScope } from './work-scope';
+import { AboutDialog } from '../features/about/AboutDialog';
type AppArea = 'db-structure' | 'data-hub' | 'dashboard' | 'graph' | 'work' | 'results';
@@ -65,13 +66,15 @@ export function App() {
const [dataHubClientView, setDataHubClientView] = useState(false);
const [dataHubDetailClientName, setDataHubDetailClientName] = useState();
const [pathSnapshotRequest, setPathSnapshotRequest] = useState<{ id: string; path: PathSnapshotState }>();
+ const [aboutOpen, setAboutOpen] = useState(false);
const { dataset, activeSheet, reviews, snapshot, theme, setTheme, delimiter, setDelimiter, view, setView, actionOnly, sidebarCollapsed, toggleSidebar, toggleWorkspace, backendStatus, targetProjectId } = app;
const marked = Object.values(reviews).filter(review => review.include).length;
const visible = useFilteredRecords().length;
const backendLabel = backendStatus === 'connected' ? 'Server connection available' : backendStatus === 'checking' ? 'Checking server connection' : 'No server connection';
- const hasClientTimeslotScope = !targetProjectId || Boolean(app.activeScanRunIds?.length);
+ const hasClientTimeslotScope = !targetProjectId
+ || hasSelectedTimeslotScope(app.activeScanRunIds, app.activeAssessmentIds);
const headerClientName = (activeArea === 'data-hub' && dataHubClientView ? dataHubDetailClientName : activeProjectName)?.trim();
const handleDataHubDetailViewChanged = useCallback((isDetailView: boolean, clientName?: string) => {
setDataHubClientView(isDetailView);
@@ -101,7 +104,7 @@ export function App() {
return
The imported package, its classifications, and its stored analyses will be permanently deleted. Baselines already referenced by policy evaluations remain protected and cannot be deleted.
- Backup configuration evidence only. Effective application is not verified without RSoP or GP Results.
- Summary and review counts represent the current active snapshot chains. Evaluation history remains auditable below.
+ Backup settings are compared with the imported Microsoft Security Baselines. Effective application requires RSoP or GP Results.
{!hasPipelineData ?
No policy analysis runs yet
Imported GPO backups remain processing evidence until snapshot aggregation and baseline evaluation have run.
+ Conflicts{currentSummary.conflicts}Different customer values for the same setting.
+ Unresolved settings{currentSummary.unresolvedIdentities}Could not be mapped to a known policy setting.
+ Unsupported settings{currentSummary.catalogGaps + currentSummary.parserGaps}No parser or baseline mapping is available.
+