Use Case

Security finding translation
into language developers can act on

A finding leaves security in CWE, CVSS, and scanner shorthand and arrives at engineering as an abstraction the developer has to decode before the fix can start. Run security finding translation on the engagement record so each finding ships to engineering with the concrete sentence-form description, the calibrated severity rationale, the engineering coordinate of the affected location, a runnable reproduction script, a verifiable fix expectation, and named acceptable closure evidence attached as one record. The remediation conversation starts on the translated finding, not on the rediscovery.

Get Started Free

No credit card required. Free plan available forever.

The remediation gap is a translation gap, not an engineering effort gap

A finding leaves the security team in security framing (CWE-79, CVSS 7.5, “Reflected XSS in user input handler”) and arrives at engineering as an abstraction the developer has to decode. The first hour of remediation is not the fix; it is the developer asking what the scanner output actually means in the deployed application, where in the codebase the issue lives, and what counts as an acceptable closure. The cycle repeats per finding, per engagement, and per release, and the cumulative latency dominates mean time to remediate more than engineering effort does.

A translated finding is one the developer can act on without re-discovering the work the security team already did. This page is the content discipline that runs inside the evidence-package structure: how to convert security vocabulary (CWE class, CVE identifier, CVSS vector, scanner module shorthand) into developer-actionable instructions naming the file, the function, the dependency, the parameter, the validation rule, the test, or the configuration value the engineer needs to change. Pair this workflow with the security finding evidence package workflow for the structural contract every finding has to carry, the SDLC vulnerability handoff workflow for how translated findings move between stage gates, and the scanner result triage workflow for the validation that decides which scanner output becomes a finding in the first place.

Six layers of a finding and how each layer translates

Translation is not paraphrasing the description into friendlier prose. It is rewriting six specific layers of the finding record so the developer reads engineering language alongside the security identifiers the auditor reads. The split below is the operating starting point internal AppSec teams, product security teams, vulnerability management teams, and security engineering teams can calibrate translation quality against.

Layer	Security framing	Developer framing
Layer 1: Title and issue-class language	CWE-79, CWE-89, OWASP A03:2021, CVSS 9.8, "Reflected XSS in search parameter", scanner module identifier, plugin ID, finding template name from the 300+ catalogue.	A title that names the specific endpoint or file, the input the user controls, the unsafe operation, and the observable consequence in concrete terms ("The /search endpoint reflects the q parameter into the response without HTML-escaping, so a request with a crafted q value executes JavaScript in the user browser"). The CWE label stays on the record for cross-reference; the developer reads the concrete sentence first.
Layer 2: Severity rationale	CVSS 3.1 vector string (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), base score 9.8, temporal modifiers, environmental modifiers, exploitability sub-score, "Critical" qualitative band.	A sentence in plain language naming why the calibrated severity is what it is ("Critical because the endpoint is unauthenticated, internet-exposed, and a successful exploit reads any user session token"). The CVSS vector stays on the record as the structured input; the developer reads the rationale and can challenge it against engineering judgement of impact.
Layer 3: Affected location	"Web application", "the API", "user input handler", "authentication module", verified_domain reference, repository slug, URL path pattern, parameter name in scanner shorthand.	For runtime findings, the verified domain plus the specific URL path plus the parameter name plus the credential class used during testing. For code findings, the repository, the file path, the line range, the function name, and the commit reference attached through repository connections. The developer reads the location and goes straight to it instead of searching the codebase from a description.
Layer 4: Reproduction script	Burp Suite request, Nessus plugin output, scanner-native payload reference, "modify the q parameter to inject a script tag", screenshot of the proxy view, hex dump of the request.	Numbered steps that name the environment, the user role, the input, the request method, the relevant headers, the body, the expected response, and the observed deviation. The full request and response live on the finding as structured artefacts so the developer can copy them into curl, into a test, or into a HAR file. Screenshots support the artefact rather than replacing it.
Layer 5: Fix expectation	"Validate user input", "use parameterised queries", "sanitise output", "follow secure coding practices", "patch to the latest version", "implement defence in depth", "apply the principle of least privilege".	A verifiable claim that names the code change ("Replace the string-concatenated SQL in UserRepository.findByEmail with a parameterised statement using the existing JdbcTemplate.queryForObject pattern"). The fix expectation reads as engineering work, not as a recommendation. The acceptable evidence (pull request reference, SAST re-run, unit test, dependency manifest delta) is named so the developer knows what closure looks like before starting.
Layer 6: Closure binding	"Findings will be retested", "validate the fix", "verify remediation", "confirm closure", a generic retest commitment without a script or an evidence standard.	The retest plan reads the same reproduction script the original finding documented, against the same environment and input. The retest evidence (re-run request and response, SAST or SCA re-run, configuration verification) attaches to the same finding record and the state moves to verified closed. A regression at retest reopens the same record with the new context. The developer reads what closure looks like and what counts as proof.

Eight failure modes that turn translation into a per-finding negotiation

Translation quality rarely fails at a single moment. It degrades in small accommodations: a scanner identifier copied into the title, a CVSS number without a rationale, a security capability label as the location, reproduction steps written for the original tester. Each accommodation is reasonable in isolation; the cumulative effect is a backlog where every handoff is a bespoke negotiation rather than a default-quality record.

Security vocabulary leaks through to the engineering ticket unchanged

The finding ships to the developer with the scanner output title ("Plugin 12345: Possible information disclosure"), the CWE identifier as the description ("CWE-200 Exposure of Sensitive Information to an Unauthorized Actor"), and the CVSS vector as the severity. The developer reads three abstract identifiers, decodes them, and then asks the security team what to actually change. The fix is treating the security vocabulary as structured metadata on the record (CWE, CVSS, scanner module, template ID) and writing the concrete engineering claim in the description, the reproduction steps, and the fix expectation.

Severity is delivered as a number without a rationale

The finding lands with a CVSS 9.8 Critical label and no explanation of why the calibration reads that way for the deployed environment. The developer disputes the severity with engineering judgement ("the affected endpoint is only reachable from the internal admin VLAN, this should not be Critical"), the security team re-defends the original score, and the calibration conversation happens after the fix is already partly scoped. The fix is writing the severity rationale on the record at finding open in plain language so the developer reads the calibrated severity with the reason attached.

Affected location is named in security framing rather than engineering framing

The finding names "the authentication module", "the user input handler", "the data access layer", or "the web application" as the affected location. The developer maps that abstract description back to a file or a function and gets it wrong half the time because the security framing groups by capability and the engineering framing groups by package. The fix is binding the finding to the repository, the file path, the line range, and the commit reference for code findings, and to the verified domain plus URL plus parameter for runtime findings, so the developer reads the engineering coordinate from the start.

Reproduction is documented for the security tester rather than for the engineering reader

The reproduction step list reads as the testers personal notes to themselves: "fired the standard XSS payload set against /search, got a hit on the third payload, see the Burp tab attached". The developer reads it, asks three clarifying questions (which Burp tab, which payload set, which environment, which role), and the security team eventually re-pairs to walk through the reproduction. The fix is writing the reproduction script as a runnable contract for the next reader: name the environment, the user role, the input, the request method, the relevant headers, the expected response, and the observed deviation.

Fix recommendation is a security-team noun phrase, not an engineering claim

The fix expectation reads "Apply input validation", "Use parameterised queries", "Patch to the latest version", or "Implement defence in depth". Each phrase is technically correct and operationally useless because none of them name the code change the developer is expected to make in this codebase. The fix is writing the verifiable claim against the named module, the named function, and the named dependency ("Replace the string-concatenated SQL in UserRepository.findByEmail with the parameterised JdbcTemplate.queryForObject helper used elsewhere in the repo"). The recommendation reads as a pull request brief.

Acceptable evidence is implicit instead of named

The fix expectation does not name what counts as closure evidence. The developer ships a fix, the security reviewer reads it, says "that does not address the issue", and the developer asks "what would". The cycle repeats once or twice per finding and the closure throughput drops by half. The fix is naming the acceptable evidence on the record before the handoff (pull request reference, SAST re-run output, dependency manifest delta, configuration diff, unit test that exercises the original payload) so the developer reads what closure looks like rather than discovering it through rework.

The conversation happens in security shorthand the developer does not share

A security reviewer writes "TOCTOU between the path check and the open call" or "JWT alg confusion via none acceptance" or "prototype pollution through merge of untrusted source object" on the finding. The developer reads three jargon nouns, looks each one up, and then has to map the abstract concept back to the codebase. The fix is keeping the security identifier on the record for cross-reference and writing the concrete engineering description alongside it ("Between the os.path.exists check on line 84 and the open call on line 91, the file path is unchecked for a race; an attacker can swap the file in that window"). The developer reads the engineering description; the auditor reads the identifier.

Translation effort scales with engineer pushback instead of with finding volume

The first time a finding gets translated, the security reviewer writes it carefully because the engineer pushed back the previous time. The next ten findings of the same class get the original scanner output because nobody complained yet. The translation discipline is reactive to complaints rather than baked into the workflow. The fix is treating translation quality as a property of the finding template, the engagement open checklist, and the handoff state event, so every finding of every class gets translated by default, not just the ones that prompted a previous complaint.

Six fields the translated finding has to carry

A defensible translation is six concrete fields on the finding record, not a paragraph in a style guide. Anything missing from the list below is a translation gap the developer pays for at handoff and the auditor pays for at lookback.

Concrete sentence-form title and description

The title and description name the asset, the input, the unsafe operation, and the observable consequence in plain language. The closest 300+ template match seeds the structured description so the issue-class wording stays consistent across engagements, and the free-text addendum names the deployment-specific context the developer needs.

Severity rationale alongside the calibrated CVSS vector

The CVSS 3.1 base vector stays on the record as the structured input. The rationale (why the environmental modifiers read the way they do for this deployed asset) is written on the same record in plain language so the developer reads the calibrated severity with the reason attached.

Engineering-coordinate affected location

For runtime findings, the verified domain plus URL plus parameter plus credential class. For code findings, the repository plus file plus line range plus function name plus commit reference attached through repository connections. The location is an engineering coordinate, not a security capability label.

Reproduction script written for the next reader

Numbered steps a developer can re-run from a cold start, with the environment, the user role, the input, the request method, the relevant headers, the expected response, and the observed deviation named. The full request and response or the SAST trace attaches to the finding as a structured artefact, not just as a screenshot.

Fix expectation as a verifiable engineering claim

The recommendation names the code change the developer is expected to make in this codebase, against the named module, function, or dependency. The claim reads as a pull request brief rather than as a noun phrase from a security style guide.

Acceptable closure evidence named on the record

The pull request reference, the SAST or SCA re-run output, the dependency manifest delta, the configuration diff, and the unit test that exercises the original payload are named as the evidence the closure decision will read against. The developer reads what counts as closure before starting, not after the rework cycle.

Seven worked translations across common issue classes

The table below shows the security framing the scanner or the tester typically produces next to the developer framing the translated record should carry. The pattern repeats across issue classes: name the deployed asset, name the engineering coordinate, name the observable consequence, and name the code change in concrete language a developer can act on without rediscovering the work.

Issue class	Security framing	Developer framing
Reflected XSS	CWE-79 Improper Neutralization of Input During Web Page Generation; CVSS 6.1 Medium; OWASP A03:2021 Injection; "User input is reflected without output encoding".	The /search endpoint reflects the q query parameter into the HTML response without HTML-escaping. A request to /search?q=<script>alert(1)</script> returns the script tag unescaped in the search-results template, and the browser executes the JavaScript. Replace the inline rendering of q with the framework template-engine escape helper that already escapes the other variables in the same template.
SQL injection	CWE-89 Improper Neutralization of Special Elements used in an SQL Command; CVSS 9.8 Critical; OWASP A03:2021 Injection; "User input is concatenated into a SQL query without parameterisation".	UserRepository.findByEmail at src/repos/UserRepository.java line 47 concatenates the email argument directly into a SQL string with the existing connection. Replace the concatenation with the JdbcTemplate.queryForObject pattern used in UserRepository.findById a few lines below, which uses ? placeholders bound from the method arguments. Acceptable closure evidence is the pull request reference, the SAST re-run that no longer flags the method, and a unit test that calls findByEmail with the original payload and confirms the query is parameterised.
Insecure deserialization	CWE-502 Deserialization of Untrusted Data; CVSS 8.1 High; OWASP A08:2021 Software and Data Integrity Failures; "Untrusted serialised data is deserialised without integrity validation".	The /session/restore endpoint reads the session-state body, base64-decodes it, and passes the bytes to ObjectInputStream.readObject in SessionRestoreController.restore at src/controllers/SessionRestoreController.java line 62. A serialised payload of a gadget class on the classpath executes during readObject and returns control to the attacker. Replace the binary deserialisation with the JSON parser the rest of the API uses, validated against the session-state schema declared in src/schemas/SessionState.schema.json.
Vulnerable dependency	CVE-2024-XXXXX; CVSS 9.0 Critical; CWE-1395 Dependency on Vulnerable Third-Party Component; "Project uses a vulnerable version of library X with a published exploit".	package.json line 23 pins lodash to 4.17.20. The published exploit affects every version below 4.17.21. Upgrade to 4.17.21 (the minimum patched version) or to the current stable 4.17.x release; the change is a single-line bump in package.json, a regenerated package-lock.json, and a test suite run. Acceptable closure evidence is the manifest delta, the SCA re-run that no longer flags lodash, and the CI build passing on the upgraded version.
Missing authorisation check	CWE-862 Missing Authorization; CVSS 8.1 High; OWASP A01:2021 Broken Access Control; "Endpoint does not verify caller authorisation".	GET /api/orders/{id} returns the order detail for any caller with a valid session, including orders that belong to other tenants. OrderController.getById at src/controllers/OrderController.java line 38 does not check that the order tenant_id matches the caller tenant_id. Add the tenant ownership check using the existing TenantService.assertOwnership helper used by the other order endpoints, and add a test that asserts a 403 response when the caller tenant does not match.
Hardcoded credential	CWE-798 Use of Hard-coded Credentials; CVSS 7.5 High; OWASP A07:2021 Identification and Authentication Failures; "Credentials are embedded in source code".	src/integrations/PaymentGatewayClient.java line 17 hardcodes the staging gateway API key as a string constant. Move the constant to the existing environment-variable resolution helper EnvConfig.requireSecret, which the rest of the integration clients in src/integrations use, and remove the hardcoded string. Rotate the previous staging key after the change ships. Acceptable closure evidence is the pull request reference, the secret scanner re-run, and a unit test that asserts the constructor reads from EnvConfig.
TLS misconfiguration	CWE-326 Inadequate Encryption Strength; CVSS 5.3 Medium; OWASP A02:2021 Cryptographic Failures; "Server accepts TLS 1.0/1.1 with weak cipher suites".	The api.acme.com TLS termination on the load balancer accepts TLS 1.0 and TLS 1.1 with cipher suites including RC4-SHA. The accepted version and cipher list lives in infra/lb/listeners.tf line 41. Update the listener policy to ELBSecurityPolicy-TLS13-1-2-2021-06 (TLS 1.2 minimum, modern cipher suites), apply the Terraform change, and verify with testssl.sh against the load balancer. Acceptable closure evidence is the infrastructure-as-code commit, the testssl.sh report, and the SSL Labs grade after the change.

Translation operating checklist

At finding open, at handoff, and at retest, the security reviewer walks a short checklist against the record. Each item takes minutes; missing any one of them is the source of the failure modes above and the rework cycles that follow.

At finding open, set the title and description in concrete asset-and-input-and-consequence language; keep CWE, CVE, CVSS vector, and scanner module identifier on the record as structured metadata for cross-reference rather than as the primary description
Write the severity rationale alongside the calibrated CVSS 3.1 vector at finding open, naming why the environmental modifiers read the way they do for the deployed asset
Bind the affected location to an engineering coordinate: verified domain plus URL plus parameter plus credential class for runtime findings, repository plus file plus line range plus function plus commit reference for code findings
Write the reproduction script for the next reader, not for the original tester, naming environment, role, input, request, expected and observed response in concrete language
Attach the full request and response (or the SAST trace) as a structured artefact on the finding so the developer can copy the exchange into a test or into curl rather than into prose
State the fix expectation as a verifiable engineering claim against the named module, function, or dependency; name the acceptable closure evidence (pull request reference, SAST or SCA re-run, dependency manifest delta, configuration diff, unit test) on the same record
Bake translation quality into the finding template, the engagement open checklist, and the handoff state event so every finding is translated by default, not just the ones that prompted a previous complaint
Hand the finding to the developer through team management RBAC for in-workspace engineers, or through the branded client portal for cross-organisation engineers, so the translated record is what the developer reads
When the developer pushes back on severity, location, or fix expectation, capture the response on the finding so the next reader sees the calibration history rather than reconstructing it from chat
At retest, read the same reproduction script the original finding documented, attach the retest evidence to the same record, and move the state to verified closed on the same finding
Run AI report generation against the engagement so the leadership view, the developer work-item summary, and the audit lookback all read against the same translated record
Review translation quality on a recurring cadence using continuous monitoring scan history and the activity log, treating consistently long handoff cycles on a finding class as a translation gap to fix in the template

How translation runs on the SecPortal record

Translation runs on the same feature surfaces the rest of the security programme already uses: findings management, finding templates, repository connections, code scanning, document management, the client portal, AI report generation, bulk finding import, and the activity log. The discipline is writing the translated record on the engagement so the developer, the security reviewer, the leadership view, and the audit lookback all read against the same source.

Findings management as the translation record

Every finding lives in findings management with the calibrated CVSS 3.1 vector, the affected asset, the named owner, and the structured description sourced from the 300+ template library. The structured field set keeps the security vocabulary on the record as cross-reference metadata while the description, the reproduction script, and the fix expectation carry the engineering language the developer reads first.

Finding templates as translation defaults

The 300+ finding templates ship with issue-class descriptions and remediation guidance that already read in engineering-actionable language. Teams that adopt templates as the default for every finding class get translation quality from the first save instead of from a later cleanup pass. Template-level edits propagate the translation improvement across every future finding of the same class.

Repository connections for code-coordinate binding

For code findings, repository connections through GitHub, GitLab, or Bitbucket OAuth let the file path, line range, function name, and commit reference appear on the finding. The developer reads the engineering coordinate of the issue and goes straight to the file instead of mapping a security-capability label back to the codebase.

Code scanning for engineering-readable evidence

Code scanning (Semgrep SAST and dependency analysis) generates the entry point, the sink, the file path, and the line numbers along the path. The developer reads the trace in engineering coordinates rather than as a security-vocabulary summary, and the retest re-runs the same scanner against the same scope so closure evidence matches open evidence.

Document management for the reproducible artefact

The structured request and response, the SAST trace, the configuration diff, and the supporting screenshots attach through document management on the engagement. The developer can copy the captured exchange into a test, into curl, or into a HAR file rather than translating a screenshot into a runnable script.

Client portal for cross-organisation translation

When the developer sits in a different organisation (a vendor team, a client engineering team, a contracted developer), the branded client portal on the tenant subdomain grants scoped access to the translated finding record. The cross-organisation developer reads the same engineering-language description, severity rationale, location coordinate, reproduction script, and fix expectation the internal engineer would read, without needing full workspace access.

AI report generation against the translated record

AI report generation derives the executive narrative, the technical writeup, and the developer work-item summary from the live finding record. The leadership view reads the calibrated severity rationale, the developer view reads the engineering claim, and the audit lookback reads the structured metadata, all from the same source so the translation does not fragment across deliverables.

Activity log as the translation history

Every state event (finding opened, description revised, severity recalibrated, fix expectation refined, handed off, retested, reopened, closed, accepted with exception) lands on the activity log with timestamp and user attribution. The CSV export is the trail an SOC 2, ISO 27001, PCI DSS, or NIST SP 800-53 review reads behind the closure claim, and the same log surfaces translation-quality improvements over time.

Bulk finding import for translated batches

Bulk finding import from Nessus (.nessus), Burp Suite (.xml), or any CSV with custom column mapping lands the source-tool output on the engagement record. The translation discipline runs against the imported set: title and description rewritten in engineering language, severity rationale added, location bound to engineering coordinates, fix expectation written as a verifiable claim, before the developer reads the finding.

What auditors expect from translated findings

Translated findings carry the structured security metadata the auditor reads behind the framework adoption claim and the engineering-actionable description the assessor reads as evidence the programme is operating, not just published. The frameworks below all expect the programme to demonstrate that the security team produces records developers can act on without rediscovery, and that the closure trail reads back to the original finding.

Framework	What the audit expects
ISO 27001 Annex A	A.8.8 (management of technical vulnerabilities) for the calibrated severity, the structured remediation guidance, the named owner, and the closure trail per finding; A.5.36 (compliance with policies and standards) for the recorded fix expectation and acceptable evidence standard; A.5.16 (identity management) for the routed developer access through team management RBAC or the client portal. The translated finding record is the operating evidence behind the clause, not a parallel narrative document.
SOC 2 (TSC)	CC2.1 (communication of internal control responsibilities) for the engineering-readable description and fix expectation per finding; CC4.1 (monitoring activities) for the retest cadence reading against the recorded reproduction script; CC7.1 (system monitoring) for the source detection and the calibrated severity; CC7.4 (responding to security incidents) for the structured handoff and closure trail. Translation quality is reviewable as a property of the record.
NIST SP 800-53 Rev. 5	RA-5 (vulnerability monitoring and scanning) for the source detection and the calibrated severity with rationale per finding; SI-2 (flaw remediation) for the fix expectation, the acceptable evidence, the closure criteria, and the retest binding; AT-3 (role-based training) for the engineering-readable description that supports developer remediation work. The translated finding is the artefact the assessor reads against the controls.
PCI DSS v4.0	6.3.3 (remediating identified vulnerabilities) for the verifiable fix expectation and the acceptable evidence per finding; 11.3 (vulnerability management programme) for the calibrated severity rationale and the closure trail; 11.4 (penetration testing programme) for the structured finding record and the retest binding. The translated record is the operating evidence the QSA reads behind the remediation claim.
NIST SSDF (SP 800-218)	PW.7 (review and analyse human-readable code to identify vulnerabilities) for the engineering-coordinate location and the file-level fix expectation; PW.8 (test executable code to identify vulnerabilities) for the reproduction script and the retest evidence binding; RV.1 (identify and confirm vulnerabilities) for the calibrated severity rationale on the record. Translation discipline is the input that turns the framework into engineering work.
OWASP SAMM	Verification function (Issue Management practice) for the engineering-readable description, the calibrated severity rationale, the fix expectation, and the named acceptable evidence; Implementation function (Defect Management practice) for the retest cadence reading the recorded reproduction script; Education and Guidance practice for the template-level translation that scales across engagements. Translation quality supports the maturity-level claims that depend on consistent developer-actionable findings.

Where translation sits in the wider security programme

Translation is the per-finding content discipline that sits between intake and remediation closure. It composes with the rest of the programme so the language of each finding stays connected to the cross-engagement, programme-level, and reporting work running alongside it.

Upstream and adjacent

Translation depends on vulnerability finding intake for the structured capture every finding starts as, scanner result triage for the validation that decides which scanner output becomes a finding, vulnerability finding CVE and EPSS enrichment for the upstream advisory context the security identifiers reference, and the security finding evidence package workflow for the structural contract translation runs inside.

Downstream and reporting

Translated findings feed SDLC vulnerability handoff for the stage-gate movement, security finding ownership and routing for the named-owner resolution, security finding fix verification for the closure cadence, remediation tracking for the programme-wide closure trail, and security leadership reporting for the cadence leadership reads the translated record against.

Pair the translation workflow with the buyer and operator material

Translation is operational; the surrounding research and operator material explain the throughput and economics inputs the translation discipline calibrates against. Pair this workflow with the security engineering handoff latency research for the leading-indicator measurement on time-to-acknowledged-ownership, the vulnerability remediation throughput research for the cycle-time inputs translation quality moves, the secure code review checklist for the upstream review discipline the translated finding feeds, the security champions program guide for the cross-team programme that scales translation quality across engineering, and the automating security findings management guide for the structured-record patterns translation runs on top of.

Adjacent personas this workflow serves

Translation quality is read by every persona that touches a finding. The list below pairs the workflow with the audience pages that describe how each role consumes the translated record.

AppSec teams

The team that authors the translation at finding open and reviews it at retest.

Product security teams

PSIRT operators who run translation across the deployed product surface and the vendor-disclosure inbound stream.

Security engineering teams

Engineers who maintain the templates, the open-checklist, and the workspace conventions translation quality scales with.

Vulnerability management teams

Operators who run the queue against translated findings and measure handoff cycle time across engagements.

Application security program leads

Leads who use translation-quality signals to fund template improvements, reviewer guidance, and security-champion programmes.

Internal security teams

Generalist internal teams that own the translation discipline across scanner output, manual testing, and third-party report intake.

Frequently asked questions

How is security finding translation different from the security finding evidence package?

The security finding evidence package workflow is the structural contract: the six layers (title, severity, location, reproduction, fix expectation, closure binding) that every finding has to carry as fields on the record. The translation workflow is the content discipline that runs inside those layers: the title is written in concrete sentence form rather than as a scanner identifier, the severity is delivered with a rationale rather than as a bare CVSS score, the location is an engineering coordinate rather than a security-capability label, the reproduction is a runnable script rather than a tester note, the fix expectation is a verifiable engineering claim rather than a security-vocabulary noun phrase, and the closure binding names what evidence counts. The evidence package is the structure; translation is the language the structure carries.

Where do CWE, CVE, and CVSS belong on a translated finding?

On the record as structured metadata fields, not in the description the developer reads first. CWE is the issue-class cross-reference the security team uses to scan across engagements and the auditor uses to map to control statements. CVE is the upstream advisory reference for dependency findings. The CVSS 3.1 vector is the structured severity input. All three stay on the record because they make cross-engagement search, audit lookback, and framework mapping defensible. The description, the reproduction script, and the fix expectation carry the engineering language the developer needs first, with the security identifiers available for cross-reference rather than as the primary description.

Does the platform automatically translate findings into developer language?

The platform structures the record so the translation field set is explicit (calibrated CVSS vector, rationale, affected asset, repository binding, reproduction artefacts, fix expectation, acceptable evidence), and the 300+ finding templates ship with issue-class descriptions and remediation guidance that already read in engineering-actionable language. AI report generation drafts the leadership and developer narratives from the live record. The security reviewer is the author of the calibrated severity rationale, the deployment-specific reproduction script, and the codebase-specific fix expectation. Translation quality is the work the platform supports rather than replaces; the structure, the templates, and the AI drafting handle the volume, the reviewer judgement makes the translation defensible.

How do we handle severity disputes between security and engineering?

Capture the engineering response on the finding record rather than in chat or on a meeting note. The CVSS 3.1 environmental modifiers are the structured place where the deployment context (tenancy isolation, exposure to the internet, data sensitivity, compensating controls already in place) updates the calibrated severity, and the rationale on the record names why the recalibration reads the way it does. If engineering successfully argues that the affected endpoint is internal-only and behind an additional authentication layer, the environmental modifiers update, the rationale records the reason, and the activity log captures the recalibration with timestamp and user attribution. The audit lookback reads the severity-history conversation as one record rather than reconstructing it from a chat search.

What is the right level of language detail for a fix expectation?

The fix expectation should read as a pull request brief. It names the file or module, the function or method, the change to be made, and the existing helper or pattern in the codebase the change should mirror. It is not "fix the SQL injection". It is "Replace the string-concatenated SQL in UserRepository.findByEmail at src/repos/UserRepository.java line 47 with the JdbcTemplate.queryForObject parameterised pattern used by findById a few lines below". It is not "patch the library". It is "Upgrade lodash in package.json from 4.17.20 to 4.17.21 minimum, regenerate package-lock.json, run the test suite". The level of detail is the level a developer can act on without rediscovering the work, which is also the level the closure decision can read against.

How does translation apply to dependency vulnerability findings?

For dependency findings, the security framing is CVE plus CVSS plus advisory link plus CWE-1395 plus affected version range. The translation is the manifest line ("package.json line 23 pins lodash to 4.17.20"), the minimum patched version ("upgrade to 4.17.21 or to the current 4.17.x stable"), the upgrade scope ("single-line bump, regenerated lockfile, test suite run"), and the acceptable evidence ("the manifest delta, the SCA re-run that no longer flags lodash, the CI build on the upgraded version"). The developer reads the engineering work; the auditor reads the CVE on the same record. The dependency vulnerability triage workflow uses translated findings as its operating record.

Should translation differ for runtime findings versus code findings?

The discipline is the same, the coordinate set differs. Runtime findings bind to the verified domain plus URL plus parameter plus credential class plus the structured request and response. Code findings bind to the repository plus file plus line range plus function plus commit reference plus the SAST trace from entry point to sink. The fix expectation differs in the same way: a runtime finding usually names the framework template, the route handler, the configuration value, or the proxy rule to change; a code finding usually names the file, the function, the dependency, or the test to add. Both translations follow the same six-field record structure and the same template-as-default principle.

How do we keep translation consistent across multiple security reviewers?

Translation consistency lives in three places: the 300+ finding template library is the default issue-class language so the description reads consistently before any reviewer touches it; the engagement open checklist names the fields each finding has to carry before handoff so no reviewer ships a finding with implicit fields; and the activity log captures every revision so the team can review translation-quality drift on a recurring cadence. When a reviewer rewrites an issue-class description more clearly than the template offered, the improvement propagates back to the template so the next reviewer inherits the improvement. Translation quality scales with the template library and the open-checklist discipline, not with the individual reviewer.

How does translation interact with the third-party penetration test report intake workflow?

A third-party pentest report typically ships in security framing: scanner-style titles, CWE labels, generic remediation noun phrases, and screenshots embedded in PDF prose. The translation workflow runs at intake: each PDF finding becomes a structured record on the engagement with the description, the reproduction script, the location, and the fix expectation rewritten in engineering language for the deployed environment. The CWE and the original tester evidence stay attached for cross-reference; the developer-facing description carries the translation. The third-party penetration test report intake workflow describes the broader intake mechanics; this workflow is the content discipline that runs inside it.

Where does AI report generation fit in the translation workflow?

AI report generation drafts the executive summary, the technical writeup, and the developer work-item summary from the live finding record. The drafts inherit the translation quality of the underlying record: if the description, the severity rationale, the location, the reproduction, and the fix expectation are written in engineering language on the finding, the developer work-item summary reads in engineering language. If the underlying finding is still in security framing, the AI summary cannot rescue it. AI report generation is a multiplier on translation quality, not a substitute for it. The security reviewer authors the translation on the finding record; AI drafts the deliverable views from the translated source.

Does the platform connect translated findings to engineering ticketing systems?

No. SecPortal does not synchronise findings to Jira, ServiceNow, Linear, Azure DevOps, or any external ticketing system. The translated finding lives on the engagement record in SecPortal, and engineering reads it through workspace team management RBAC (member or viewer roles) or through the branded client portal on the tenant subdomain for cross-organisation cases. Programmes that need the translated finding to appear inside an engineering ticket maintain that copy outside the platform; the SecPortal record remains the source of truth for the calibrated severity, the rationale, the location, the reproduction, the fix expectation, the acceptable evidence, and the closure trail.

How do we measure translation quality over time?

Two recurring signals work well: handoff cycle time per finding class (the duration from finding open to acknowledged engineering ownership read against the activity log timestamps) and rework rate per finding (the number of state transitions between handed off and reopened before verified closed). Consistently long handoff cycles or high rework rates on a finding class are a translation gap to fix in the template, the open checklist, or the reviewer guidance. The activity log CSV export feeds the measurement, and AI report generation can summarise the trend across engagements for the cadence leadership reads against.

Scope and limitations

What this workflow does and does not cover

The translation workflow operates against the SecPortal engagement record. The platform structures the field set (CVSS 3.1 vector, environmental rationale, affected asset, repository connection, reproduction artefact, named owner, fix expectation, acceptable evidence, closure state), ships 300+ finding templates with default issue-class language, and drafts deliverable views through AI report generation. The security reviewer is the author of the deployment-specific translation: the codebase-specific fix expectation, the environment-specific severity rationale, the runnable reproduction script.

SecPortal does NOT synchronise translated findings to Jira, ServiceNow, Linear, Azure DevOps, or any external engineering ticketing system. It does NOT publish translated findings to Slack, Microsoft Teams, PagerDuty, or any external messaging integration. It does NOT ship with a built-in semantic similarity engine that maps free-text scanner output to engineering-language descriptions automatically. It does NOT replace the security reviewer judgement that turns a CWE class and a CVSS vector into a verifiable engineering claim against the deployed codebase.

Programmes that need translated findings to appear inside an engineering ticket maintain that copy outside the workspace; the SecPortal engagement record remains the source of truth the calibrated severity, the rationale, the location coordinate, the reproduction script, the fix expectation, the acceptable closure evidence, and the closure trail bind to.

How it works in SecPortal

A streamlined workflow from start to finish.

Keep security identifiers as metadata, write engineering language as the description

At finding open, capture CWE, CVE, CVSS 3.1 vector, scanner module, and template identifier as structured metadata fields on the record so cross-engagement search, audit lookback, and framework mapping stay defensible. Write the title and description in concrete asset-and-input-and-consequence sentence form so the developer reads engineering language first, with the security identifiers available for cross-reference rather than as the primary description. Pick the closest of the 300+ finding templates so the issue-class wording stays consistent across engagements and the reviewer starts from translated default language.

Write the severity rationale alongside the calibrated CVSS vector

Keep the CVSS 3.1 base vector and the environmental modifiers as the structured severity input. Write the rationale on the same record in plain language naming why the calibration reads the way it does for the deployed asset (tenancy isolation, exposure to the internet, data sensitivity, compensating controls already in place). The developer reads the calibrated severity with the reason attached and the engineering response (severity dispute, environmental update, compensating control confirmation) lands on the same record rather than in a meeting note.

Bind the affected location to an engineering coordinate

For runtime findings, attach the verified domain plus URL plus parameter plus credential class used during testing. For code findings, attach the repository connection (GitHub, GitLab, or Bitbucket OAuth), the file path, the line range, the function or method name, and the commit reference so the developer reads the engineering coordinate of the issue. The location reads as a file the developer opens, not as a security capability label they have to map back to the codebase.

Write the reproduction script for the next reader, not for the original tester

Capture the reproduction in the order a developer can re-run it from a cold start. Name the environment, the user role, the input, the request method, the relevant headers, the body, the expected response, and the observed deviation in concrete language rather than in tester shorthand. Attach the full request and response or the SAST trace as a structured artefact through document management so the developer copies the exchange into a test or into curl rather than translating a screenshot into a runnable script.

State the fix expectation as a verifiable engineering claim

Write the fix expectation as a pull request brief: name the file or module, the function or method, the change to be made, and the existing helper or pattern in the codebase the change should mirror. Replace generic noun phrases ("apply input validation", "use parameterised queries", "patch to the latest version") with the named code change the developer is expected to make. Name the acceptable closure evidence (pull request reference, SAST or SCA re-run, dependency manifest delta, configuration diff, unit test) on the same record so the developer reads what closure looks like before starting.

Hand the translated finding through the same record, not through chat

Route the finding to the developer through team management RBAC (member or viewer role on the engagement) for in-workspace engineers, or through the branded client portal on the tenant subdomain for cross-organisation engineers. The developer reads the translated description, severity rationale, location coordinate, reproduction script, fix expectation, and acceptable evidence on the same record the security team operates against. Notifications and notes attach to the finding so the audit trail does not depend on a chat search six months later.

Retest the translated record and propagate template improvements

At retest, read the same reproduction script the original finding documented in the same environment. Attach the retest evidence (re-run request and response, SAST or SCA re-run, configuration verification) to the same finding and move the state to verified closed on the same record. When a reviewer writes a clearer description, severity rationale, or fix expectation than the template offered, propagate the improvement back to the template so the next finding of the same class inherits the translation. AI report generation drafts the leadership, developer, and audit views from the live translated record so the deliverables read in the same language as the source.

Features that power this workflow

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Document management for every security engagement

Repository connections for SAST and SCA

Find vulnerabilities before they ship

Test web apps behind the login

AI-powered reports in seconds, not days

Every action recorded across the workspace

Collaborate across your entire team

Your brand. Your portal. Your clients love it.

Notifications and alerts for the people who carry the work

Bulk finding import bring your scanner data with you

Compliance tracking without a full GRC platform

Ship findings developers can act on without rediscovery

Concrete sentence-form descriptions, calibrated severity with a rationale, engineering-coordinate locations, runnable reproduction scripts, verifiable fix expectations, and named acceptable evidence on one engagement record. Start free.