Finding Management and Secure Code Remediation: Remediation, Retest and Security Debt

The source code analysis is complete.

The SAST scan has been done.

The manual security review has been carried out.

The critical findings have been verified.

The report has been prepared.

So what happens now?

In fact the most critical stage of Application Security programmes begins exactly here.

Because finding the vulnerability is not sufficient on its own.

The real value emerges when the flaw found is prioritised correctly, conveyed to the development team in an understandable way, fixed securely, and the fix is verified as genuinely effective.

Otherwise the security report can remain merely a document.

Critical and high findings can stay open for months.

Developers may not know which flaw should be fixed first.

The same security errors can recur in new releases.

And the organisation can meet the same findings again at every pentest or source code analysis.

A mature Application Security approach therefore does not focus only on:

Detect

— the finding stage.

It manages this life cycle:

Detect → Validate → Prioritize → Assign → Remediate → Retest → Close → Prevent

This process generally forms the application security side of the Vulnerability Management and Remediation Management approach.

In this chapter we will examine in detail how a source code security finding should be managed from the moment it is detected to the moment it is closed.

1. What Is a Security Finding?

A security finding is a weakness detected inside an application that could create a security risk.

This finding can come from different sources such as:

• SAST,
• SCA,
• Secret Scanning,
• DAST,
• Manual Code Review,
• Pentest.

For example:

SQL Injection

can be a security finding.

But the finding's name alone is not sufficient.

For a finding to be meaningful, these questions must be answered:

• Where was it found?
• Who is affected?
• How can an attacker use it?
• What is the business impact?
• Under what conditions can it be exploited?
• How can it be fixed?
• Who owns the fix?

Good finding management gathers this information into a single life cycle.

2. Tool Output and a Verified Finding Are Not the Same Thing

Automated tools such as SAST or DAST can produce a large number of potential findings.

But these outputs should not be accepted as vulnerabilities directly.

A tool might give the warning:

Potential SQL Injection

But a parameterized query may be applied at framework level.

In that case the result may be a false positive.

The first stage is therefore:

Validation

Filling the developer backlog with unverified tool output can lower the quality of the AppSec programme.

3. What Is Validation?

Validation is the assessment of whether a security finding is real and under what conditions it can be exploited.

Questions such as these can be asked:

• Is the code really reachable?
• Is the function active in production?
• Can the input be controlled by an attacker?
• Is the security control applied in another layer?
• Is the exploit scenario realistic?

As a result of this assessment the finding can be classified as:

True Positive

or:

False Positive

4. True Positive

A true positive means the situation detected really is a vulnerability.

But being a true positive does not necessarily mean the finding is critical.

An XSS flaw may be real but may affect only an internal admin user, for example.

Another XSS may affect all customers over the internet.

Both are true positives.

But their risk levels can be different.

After validation the second stage should therefore be:

Risk Prioritization

5. False Positive

A false positive is a situation the security tool marks as a problem but which is not actually exploitable.

SAST may see that user input reaches an SQL query, for example.

But the ORM in use may parameterize every query safely.

In that case there is no real SQL Injection.

Managing false positives correctly matters.

Because too many false alarms:

• reduce developer trust,
• inflate the security backlog,
• lower the visibility of real findings.

Over time this can create alert fatigue.

6. Why Is Risk Prioritisation Necessary?

An application can have hundreds of security findings.

It is not possible for the development team to fix them all at once.

The right question is therefore:

Which should we fix first?

Deciding on the scanner's severity alone is not sufficient.

Real risk consists of many factors.

For example:

• technical severity,
• exploitability,
• reachability,
• internet exposure,
• data sensitivity,
• business criticality

should be assessed together.

7. Is CVSS Sufficient for Prioritisation on Its Own?

No.

CVSS is useful for standardising technical vulnerability severity.

But it does not show the organisation's real business risk on its own.

For example:

A flaw with a CVSS score of 9.8 may be in an unused demo service.

Meanwhile a Broken Access Control flaw scored 7.5 may provide access to millions of customer records.

The second finding can be more critical for the organisation.

Risk assessment must therefore go beyond the technical score.

8. Business Criticality

The application's importance to the business plays a large role in risk prioritisation.

The same vulnerability in:

• a corporate intranet application,
• an internet banking system

should not be assessed at the same level.

Criticality levels can therefore be assigned to applications.

For example:

Tier 1 – Critical

Tier 2 – High

Tier 3 – Standard

Tier 4 – Low

The AppSec risk model can use this classification.

9. Internet Exposure

Systems reachable over the internet generally have a larger attack surface.

For a vulnerability in an internal application, the attacker may first need to reach the internal network.

In an internet-facing application the attacker can try the exploit directly.

Exposure can therefore affect the risk score.

But internal applications should not be thought risk-free.

Attacks such as insider threat and lateral movement can target internal systems too.

10. Reachability

Whether the code containing a vulnerability is really reachable by an attacker is an important criterion.

The vulnerable function may be inside:

• dead code,
• test code,
• a local-only tool.

In another case the same function may be called from a public API endpoint.

The technical vulnerability can be the same.

The real risk is entirely different.

Reachability therefore matters particularly for SAST and SCA findings.

11. Exploitability

Exploitability expresses how easily the vulnerability can be used in practice.

Questions such as whether the attacker:

• needs authentication,
• needs a special role,
• needs user interaction,
• needs special network access,
• needs a complex attack chain

are assessed.

A flaw exploited with a simple HTTP request and one that works only under very specific conditions may not carry the same priority.

12. Known Exploitation

If a vulnerability is known to be actively used by attackers, its priority must rise significantly.

This matters particularly in dependency security.

The SCA system may have detected a CVE.

If a public exploit exists for that flaw, or active attacks are observed, the normal remediation SLA may not be waited out.

Urgent remediation may be needed.

13. Data Sensitivity

Which data the finding provides access to also matters in risk assessment.

For example:

• public product information,
• user profiles,
• personal data,
• financial records,
• authentication credentials

have different sensitivity levels.

If an authorisation flaw provides access to sensitive financial data, the business impact will be higher.

14. The Risk Matrix

Organisations can create a simple risk matrix between technical severity and business criticality.

For example:

High Severity + Critical Application = Critical Risk

Medium Severity + Critical Application = High Risk

High Severity + Low Criticality = Medium/High Risk

This structure enriches the scanner's severity with enterprise context.

15. What Is a Critical Finding?

A critical finding is generally a security problem with very high impact and high exploitation potential.

For example:

• unauthenticated remote code execution,
• authentication bypass,
• critical SQL Injection,
• production cloud admin credential exposure

can be assessed as critical.

Findings of this kind should mostly not wait for the normal sprint plan.

An urgent remediation process may be needed.

16. High Findings

High severity findings have a serious security impact but can be more limited than the critical level.

For example:

• sensitive data access,
• serious Broken Access Control,
• a critical business logic problem,
• privilege escalation

can be assessed as high.

A defined remediation SLA can be applied for these findings.

17. Medium Findings

Medium findings carry real security risk but generally require certain conditions or have more limited impact.

It is important that they are not forgotten in the backlog.

Because attackers can sometimes combine several medium findings to create a more serious attack chain.

18. Low Findings

Low-level findings may not provide a serious exploit directly.

But they can matter from a defence-in-depth perspective.

For example:

• a missing security header,
• limited information disclosure,
• a low-impact configuration issue

can be low.

Ignoring them entirely is not right either.

19. Informational Findings

An informational finding may not be a vulnerability directly.

It can be a security improvement or best practice recommendation.

For example:

Unnecessary server version information in the HTTP response.

This may not be an exploit on its own.

But the attacker can gain information during reconnaissance.

20. What Is Remediation?

Remediation is the secure fixing of the vulnerability.

But remediation is broader than saying:

"Change the risky line."

Correct remediation:

• must eliminate the root cause,
• must not break the application's function,
• must not create a new vulnerability,
• must where possible prevent recurrence.

The security and development teams therefore need to work together.

21. Are a Patch and a Root Cause Fix the Same Thing?

Not always.

For SQL Injection the developer might block the ' character in user input.

That can stop the particular attack.

But the root cause is still there.

The right solution is to use a parameterized query.

In security remediation, therefore:

Root Cause Fix

should be preferred over:

Payload-specific fix

22. Fixing the Root Cause

If the same security problem exists in more than one place, fixing the shared component can be more effective than fixing lines one by one.

If 25 SQL Injections stem from the same unsafe database helper, for example:

instead of changing 25 different functions,

the helper can be made secure.

This approach is both faster and more sustainable.

23. What Is a Secure Fix?

A secure fix means solving the security problem in line with secure design principles instead of suppressing it temporarily.

For example:

Problem: User input is added to a shell command.

Poor solution:

Filtering a few particular characters.

Good solution:

Not calling the shell, or using a safe API.

This difference is the foundation of Secure Coding.

24. Remediation Guidance

The security report should offer the developer an applicable recommendation.

Merely saying:

"Close the SQL Injection flaw."

is not sufficient.

A better recommendation is:

"Use the relevant framework's parameterized query API instead of dynamic string concatenation."

Where possible an example specific to the technology in use should be given.

25. Unsafe and Secure Code Examples

Bad and good practice can be compared so the developer understands the problem faster.

For example:

Unsafe

Building a dynamic SQL string.

Secure

Using a prepared statement.

This approach also increases the educational value of the security report.

26. Is Remediation the Developer's Responsibility?

The developer generally makes the code change.

But the security team is part of the process too.

The security team:

• explains the risk,
• recommends the secure approach,
• assesses the design in critical cases,
• retests the fix.

This is a shared responsibility model.

27. Assigning Finding Owners

Every security finding must have a responsible owner.

For example:

• Application Team
• Backend Team
• Platform Team
• DevOps Team
• IAM Team

can be the owner.

Without an owner, the likelihood of the finding being closed falls significantly.

Automatic ticket integration is therefore useful.

28. Ticket System Integration

AppSec findings can be transferred to Jira, Azure DevOps or similar systems.

The ticket can contain:

• the finding name,
• severity,
• affected file,
• remediation,
• SLA,
• security owner.

This approach turns the PDF report into part of the developer's daily workflow.

29. The Security Backlog

If all vulnerabilities cannot be closed immediately, a security backlog is created.

But the backlog should not be merely a store of findings.

Every finding must have:

• priority,
• owner,
• deadline,
• status.

Otherwise security debt grows uncontrolled.

30. What Is Security Debt?

Security debt refers to the accumulation over time of security problems not yet resolved.

It resembles technical debt.

A team may be constantly developing new features while postponing medium security findings, for example.

Hundreds of vulnerabilities accumulate over time.

That structure can later turn into a major remediation cost.

31. How Does Security Debt Arise?

The most common causes are:

• time pressure,
• feature priority,
• legacy code,
• incorrect risk assessment,
• lack of an owner,
• insufficient resources,
• low AppSec maturity.

Security debt may not be reducible to zero entirely.

But it must be known and managed.

32. The Security Debt Inventory

The organisation must make open security debt visible.

A dashboard might show:

Critical Open: 2

High Open: 13

Medium Open: 84

Overdue: 21

This data is an important risk indicator for management.

33. The Age of Security Debt

Not only how many findings there are but how long they have been open matters.

A 400-day-old high vulnerability can point to a serious process problem, for example.

Finding age should therefore be measured.

34. What Is an SLA?

An SLA here expresses the expectation that a finding will be addressed within a defined period.

An organisation's policy might be:

Critical: 3 days

High: 15 days

Medium: 45 days

Low: 90 days

These periods are examples.

They should be determined according to the organisation's sector, regulation and risk appetite.

35. Should the Normal SLA Be Waited Out for a Critical Vulnerability?

Not always.

If a critical RCE under active exploitation is detected on an internet-facing production system, for example, waiting out the normal SLA period may not be appropriate.

Incident response can come into play.

Temporary mitigation can be applied.

Service access can be restricted.

The permanent fix can then be made.

36. The Difference Between Mitigation and Remediation

Mitigation

is the temporary reduction of risk.

Remediation

is the permanent fixing of the root cause.

For an SSRF flaw, a WAF rule can be temporary mitigation.

Redesigning the code with an allowlist architecture can be permanent remediation.

The two should not be confused.

37. Compensating Controls

If the finding cannot be fixed immediately, another security control can be applied to reduce the risk.

For example:

• a network ACL,
• a WAF,
• feature disablement,
• access restriction

can be a compensating control.

But the control's real risk-reduction effect must be verified.

38. What Is Risk Acceptance?

Some findings can be accepted knowingly.

The cost of fixing may be very high and the real exploitability very low, for example.

Risk acceptance can be applied in that case.

But the decision must be:

• documented,
• approved,
• time-limited,
• justified.

39. Can a Developer Accept a Risk They Found Themselves?

It depends on the enterprise model, but ideally acceptance of a high risk should not be a developer decision alone.

The risk owner or the relevant management representative should approve it.

Because the technical team sees only the technical cost, while the business side is the party that carries the real risk.

40. Should Risk Acceptance Be Open-Ended?

Preferably not.

For example:

Risk accepted until next major release

or a specific date can be assigned.

When the period expires, the finding is reassessed.

Decisions taken years ago then do not remain valid for ever.

41. Exception Management

If an exception to the security policy is needed, an exception management process can be used.

The pipeline may be blocking the build because of a vulnerable dependency, for example.

The developer can prove that it is unreachable.

The security team can grant an exception for a defined period.

That exception must be recorded.

42. Are Suppression and Risk Acceptance the Same Thing?

No.

Suppression is generally used to remove technical noise.

A false positive finding is suppressed, for example.

Risk acceptance is the knowing acceptance of a real security risk.

This distinction matters.

43. What Is a Retest?

A retest is the security team verifying whether the vulnerability has genuinely been closed after the developer has fixed the finding.

This is a critical stage.

Because:

"The code has changed."

does not mean:

"The vulnerability is closed."

The fix may have been applied incorrectly.

44. How Is a Retest Done?

The method varies according to the type of finding.

For a SAST finding:

The new code can be put through SAST again.

For a business logic flaw:

Manual pentesting is needed.

For a dependency CVE:

SCA can be rerun.

For secret exposure:

It can be verified that the old credential was revoked.

The retest method must suit the nature of the finding.

45. Retest Result States

A finding can move to states such as:

Closed

The fix has been verified.

Partially Fixed

The risk has been partly reduced.

Still Open

The vulnerability persists.

Risk Accepted

No fix was made; the risk was accepted.

Not Applicable

The technical conditions have changed.

These states must have clear definitions.

46. What Is a Partial Fix?

Sometimes the developer fixes only part of the flaw.

The authorisation check has been added to two of three endpoints, for example.

The third endpoint is still open.

In that case the finding should not be marked closed.

It can remain partially fixed.

47. What if the Fix Is Correct but Incomplete?

Remediation must consider new attack paths.

The developer may have fixed the authorisation check on the /api/orders/123 endpoint, for example.

But /api/order/export/123 may still reach the same data.

A retest is therefore not merely resending the original payload.

All variations of the root cause must be examined.

48. What Is Security Regression?

A previously fixed security problem reappearing through new code changes is called security regression.

An SQL Injection was closed three months ago, for example.

Another developer used the same unsafe helper again.

The vulnerability has returned.

One-off remediation is therefore not sufficient.

49. How Is a Regression Test Created?

After the finding is closed, an automated test should be written where possible.

An integration test can be created for an authorisation flaw, for example.

A standard user tries to reach another user's data.

The test verifies the expected result:

403 Forbidden

If the control is removed in future, the test fails.

50. Can a Security Finding Be Turned into a Unit Test?

In some cases yes.

For example:

• authorisation,
• validation,
• cryptographic policy

can be checked with a unit or integration test.

This approach makes security knowledge permanent.

51. Can a Pentest Finding Be Turned into Automation?

Some pentest findings can be turned into custom SAST, DAST or regression rules.

A particular unsafe usage in the organisation's internal framework may have been discovered during a manual pentest, for example.

A custom SAST rule is written.

From then on it is checked automatically across all other repositories.

This is an important indicator of AppSec maturity.

52. What Is Finding Recurrence?

If the same CWE or the same root cause keeps recurring, finding-based remediation alone is not sufficient.

30 Broken Access Control issues may have been found within six months, for example.

In that case the problem should be seen not as:

"30 separate vulnerabilities"

but as:

"There is a systematic problem in our authorisation design."

53. Root Cause Remediation

Recurring vulnerabilities require a higher-level solution.

For example:

• a central authorisation library,
• a secure database helper,
• an approved crypto library,
• mandatory security middleware

can be created.

Secure behaviour is thus taken out of the developer's manual choice and turned into a platform standard.

54. Secure by Default Frameworks

Ideally the internal framework makes secure behaviour the default.

A new endpoint can be authenticated by default, for example.

If the developer explicitly wants to make it public, they use a special annotation.

The secure path thus becomes automatic.

This is a strong example of the Security by Design approach.

55. Finding Management and Security Champions

A security champion can help findings be understood faster within the team.

They explain the finding produced by the AppSec team to the rest of the team, for example.

They can provide technical guidance for remediation.

This structure lets security teams scale, particularly in large development organisations.

56. What Is a Remediation Workshop?

After a critical project in particular, the AppSec and development teams can assess the findings together.

During the workshop:

• the most critical vulnerabilities,
• root causes,
• recommended code changes,
• architectural fixes

can be addressed.

This is far more effective than merely sending a PDF report.

57. The Language Problem Between Security and Developers

The security specialist may say:

"CWE-639 Authorization Bypass."

The developer asks:

"Which function should I change?"

Good finding management combines these two languages.

The finding must be technically correct but also actionable from the developer's perspective.

58. What Should a Good Finding Description Look Like?

Example structure:

Risk

A standard user can reach another customer's invoices.

Root Cause

The back end does not verify object ownership.

Affected Endpoint

GET /api/invoices/{id}

Remediation

The invoice owner ID must be verified against the authenticated user ID before the query result is returned.

This format makes clear what the developer needs to do.

59. Secure Code Examples

For critical findings in particular, a secure code example suited to the framework can be given.

This shortens the developer's remediation time.

But it should be stated that copy-paste code may not suit every environment.

What matters is that the security principle is understood.

60. How Is the Security SLA Tracked?

A dashboard can be created.

For example:

• Open Critical
• Overdue High
• MTTR
• Closure Rate
• Reopened Findings

can be tracked.

These metrics show the real state of AppSec operations.

61. Mean Time to Remediate (MTTR)

MTTR is the average time from a finding being detected to it being closed.

For example:

Critical MTTR: 3 days

High MTTR: 12 days

Medium MTTR: 45 days

can be tracked.

The aim is to reduce these periods on a risk basis over time.

62. Closure Rate

This shows how many of the findings opened in a given period were closed.

For example:

100 new findings over the month.

80 findings closed.

The closure rate can be 80%.

But assessing it separately by severity is more meaningful.

63. Reopen Rate

The rate at which a closed finding is found open again at retest or in a subsequent test matters.

A high reopen rate can show that remediation quality is low.

Developer guidance should then be improved.

64. The Security Debt Trend

The total number of open findings can be tracked over time.

The aim may not always be zero findings.

But the trend matters.

If security debt keeps rising, for example, the programme is not sustainable.

The rate of new vulnerability production exceeds the rate of remediation.

65. Burn-Down

A sprint burn-down approach can be used for security debt.

For example:

At the start of the quarter:

120 high findings.

Target at the end of the quarter:

40 high findings.

A defined remediation capacity can be reserved in every sprint.

This makes security work visible.

66. Security Remediation Sprints

In legacy systems in particular, certain periods can be reserved for remediation.

But using only a separate "security sprint" permanently is not ideal.

In the long run security should be part of the normal development backlog.

67. The Priority Conflict Between Features and Security

Development teams can be under constant pressure for new features.

A vulnerability is usually not as visible as a revenue-generating new feature.

Risk management therefore requires management support.

Why a critical vulnerability should be addressed before a feature must be defined clearly.

68. Should the Product Owner Be Part of the Security Process?

Yes.

The product owner or the relevant business owner can be involved in the process regarding the application's criticality and remediation priorities.

Because security is not only a technical matter.

It is business risk.

69. The Security Risk Owner

It is useful for every critical application to have a risk owner.

This person does not have to be the technical owner.

Who takes decisions such as risk acceptance thus becomes clear.

70. Who Should the AppSec Dashboard Be For?

Different users want different information.

Developer

Wants to see their own open tickets.

Engineering Manager

Wants to see the team's security backlog.

CISO / Security Manager

Wants to see the trends across the organisation.

Executive Management

Wants to see the critical business risk.

Dashboards can be customised to these needs.

71. Should Lines of Code Be Shown to Management?

Generally not necessary.

For senior management this information is more valuable:

• how many critical vulnerabilities exist,
• which critical applications are affected,
• how many are outside SLA,
• which way the risk trend is going.

Technical detail can stay at engineering level.

72. Is an Executive Summary Enough for the Developer?

No.

The developer needs:

• file,
• function,
• line,
• root cause,
• remediation

information directly.

An AppSec report should therefore present detail at different levels.

73. Risk-Based SLAs

SLAs can be differentiated not only by severity but by asset criticality and exposure.

A shorter period can be applied for a high finding in an internet-facing Tier 1 application, for example.

A longer period can be defined for the same vulnerability in an internal Tier 4 application.

This provides more realistic risk management.

74. Dependency Remediation

For SCA findings, remediation is mostly a dependency upgrade.

But the developer should see this information:

• current version,
• vulnerable range,
• fixed version,
• breaking change risk.

A blind upgrade can create a production problem.

A testing process is therefore necessary.

75. Remediation of a Secret Finding

In secret exposure, removing it from the file is not sufficient.

The correct process is:

Revoke

↓

Rotate

↓

Repository Cleanup

↓

Log Investigation

↓

Prevention

This can be handled as a security incident.

76. Remediation of an Authorization Finding

For a Broken Access Control flaw, hiding the front-end button is not a solution.

Server-side authorisation checks must be applied on the back end.

For example:

Authenticated User

Object Ownership

Required Permission

must be verified.

If this control can be centralised, the risk of recurrence falls.

77. XSS Remediation

For XSS, filtering only the word <script> is not sufficient.

Context-aware output encoding is needed.

The modern framework's secure default features should be used.

Unsafe HTML APIs should be avoided.

78. SQL Injection Remediation

One of the strongest solutions for SQL Injection is the parameterized query approach.

Input filtering alone should not be regarded as sufficient.

Applying least privilege to the database account also provides defence in depth.

79. SSRF Remediation

For SSRF:

• allowlists,
• URL parsing,
• IP validation,
• redirect checking,
• network segmentation

can be considered together.

A single blacklist is usually not sufficient.

80. File Upload Remediation

For file upload vulnerabilities:

• allowed extensions,
• MIME verification,
• content inspection,
• random filenames,
• storage isolation,
• execution restriction

can be applied together.

The fix must cover the whole upload life cycle.

81. Code Review After Remediation

For critical findings it can be useful for the developer's fix to be examined by a security champion or AppSec via the merge request.

This catches faulty fixes early, before the retest.

82. The Fix Pull Request

A separate pull request can be created for a security finding.

The PR description can contain a ticket relationship such as:

Fixes SEC-142

Traceability between the code change and the security finding is thus provided.

83. Why Does Traceability Matter?

During a future audit these questions can be answered:

• Which finding was found when?
• Who fixed it?
• Which commit closed it?
• Who performed the retest?
• When did it go to production?

This is valuable particularly in regulated sectors.

84. Security Evidence

Evidence can be retained during the retest.

For example, evidence such as:

• scan results,
• code diffs,
• test output,
• screenshots,
• request/response

can be added to the finding record.

This is useful from an audit perspective.

85. The Security Finding Life Cycle

In a mature AppSec system the finding life cycle might be:

New

↓

Validated

↓

Assigned

↓

In Progress

↓

Fixed

↓

Retest

↓

Closed

Alternative paths can be:

False Positive

Risk Accepted

Exception

86. Workflow Automation

This life cycle can be managed with manual Excel files, but that is not sustainable in large organisations.

An AppSec platform and ticket system integration can automate the process.

A high finding can be assigned to the owner automatically, for example.

A notification can be sent as the SLA approaches.

87. Is Everything Over When a Security Finding Is Closed?

No.

For critical and recurring findings in particular, this question should be asked:

Where else are we doing this?

If unsafe crypto usage was found in one repository, for example, the other repositories should be scanned too.

This approach turns a single finding into organisational learning.

88. Horizontal Remediation

Searching for a vulnerability in other systems too can be called the horizontal remediation approach.

For example:

A hard-coded AWS key was found in one application.

The same pattern is searched for across all repositories.

A single incident thus turns into a security improvement across the organisation.

89. Vertical Remediation

Similar code paths within the same application can be examined in depth.

If an IDOR was found, for example, not only the relevant endpoint but all endpoints using the same resource are checked.

This is part of root-cause-based remediation.

90. Lessons Learned

A short lessons-learned exercise can be held after a critical security finding.

For example:

• Why did it occur?
• Why did SAST not catch it?
• Why did code review not catch it?
• Which control should be added?

The aim is not to blame a person but to improve the system.

91. Providing Data for Developer Training

Finding trends can determine the content of developer training.

If the organisation's most frequent vulnerability categories are:

• Broken Access Control
• Secret Exposure
• XSS

the Secure Coding programme can prioritise those topics.

This can be more effective than generic training.

92. Providing Data to Security Champions

Each team can be shown its own vulnerability trends.

If the payments team keeps making authorisation errors, for example, the security champion can create a specific control checklist for that area.

93. Providing Data to the Framework Team

Some recurring vulnerabilities are the platform framework's problem rather than the application developer's.

If the same unsafe logging approach exists in all teams, for example, the central logging framework can be fixed.

That is a more scalable solution.

94. The Next Level in AppSec Maturity

An entry-level organisation:

finds the vulnerability.

A better organisation:

fixes the vulnerability.

A mature organisation:

prevents the same vulnerability recurring.

Real AppSec maturity emerges at the third stage.

95. The Prevention Loop

A security finding can start this loop:

Find

↓

Fix

↓

Learn

↓

Automate

↓

Prevent

A vulnerability is found in a manual pentest, for example.

It is fixed.

A custom SAST rule is created.

The Secure Coding standard is updated.

From then on the same error is blocked at the commit stage.

This is sustainable security.

96. Should the Secure Coding Standard Be Updated Based on Findings?

Yes.

Source code analysis and pentest findings show the organisation's real development errors.

This data turns the Secure Coding standard into a living document.

If a new mass assignment problem has been found, for example, an explicit binding rule can be added to the standard.

97. Should the Security Quality Gate Be Updated Based on Findings?

Yes.

If a critical pattern keeps recurring, it can be turned into a pipeline rule.

For example:

Hard-coded production secret → Build Block

or:

Critical SAST new code finding → Merge Block

can be applied.

98. How Is Remediation Performance Measured?

Some of the important metrics can be:

• Mean Time to Remediate
• Open Critical Findings
• Overdue Findings
• Reopen Rate
• Security Debt Trend
• Recurring CWE Rate
• Fix Verification Rate

These metrics show the real effectiveness of finding management.

99. Why Does the Recurrence Rate of the Same Vulnerability Matter?

An organisation may be closing vulnerabilities very quickly.

But if the same weakness keeps recurring, the Secure Coding process is not improving.

Recurring weakness rate is therefore a valuable metric.

The aim is not only to close quickly but to reduce recurrence.

100. Which Is the Best Security Finding?

At first glance the answer may look like "the critical finding".

But in the long run the most valuable finding is:

the one that surfaces the organisation's systematic security problem.

Because fixing a single flaw protects one system.

Fixing the root cause can prevent hundreds of future vulnerabilities.

The SecureSys Finding Management and Remediation Approach

At SecureSys we believe security work is not complete merely with the detection and reporting of findings.

A security finding's real value emerges as a result of:

determining the correct risk level, conveying it to the relevant development team, fixing it securely and verifying it with a retest.

Depending on project scope, the finding management process can therefore be handled through these steps:

Validation

↓

Risk Prioritization

↓

Developer Remediation Guidance

↓

Owner Assignment

↓

Retest

↓

Closure

↓

Prevention

For critical applications in particular, doing root cause analysis matters more than a "the finding is closed" approach.

If the same security problem recurs in different applications, it should no longer be seen as an individual coding error.

The Secure Coding standard,

framework design,

the security champion model,

SAST rules

and CI/CD Quality Gate policies should be reviewed together.

The goal is not merely to reduce the existing security backlog.

The real goal is:

to reduce the number of vulnerabilities created in future.

Because a mature Application Security programme measures security success not with the question:

"How many vulnerabilities did we find?"

but with:

"By how much did we reduce the recurrence of the same vulnerability?"

Frequently Asked Questions

What is remediation?

Remediation is the process of fixing a detected vulnerability securely in a way that eliminates its root cause.

What is a retest?

A retest is the security team verifying whether the fix made by the developer genuinely closed the vulnerability.

What is security debt?

Security debt refers to the accumulation over time of vulnerabilities and security gaps not yet closed.

How quickly should a critical finding be fixed?

There is no single universal period. The organisation's risk model, the application's criticality and any active exploitation must be taken into account. Critical flaws under active exploitation can require urgent intervention.

What is a false positive?

It is a security tool reporting as a vulnerability a situation that is not actually exploitable.

What is risk acceptance?

It is the temporary or controlled acceptance of a real vulnerability with a defined justification and approval mechanism.

What is the difference between mitigation and remediation?

Mitigation reduces risk temporarily. Remediation aims to fix the vulnerability's root cause permanently.

Should every security finding be fixed immediately?

Prioritisation should be done according to criticality and real risk. But all real findings — including accepted risks — must stay visible and manageable.

Should security findings be transferred to the ticket system?

It is useful particularly in large software teams. Owner, SLA, remediation and retest processes then become part of the daily development workflow.

Is a retest necessary after a pentest?

It is recommended particularly for critical and high findings. It must be verified that the change made genuinely resolved the security problem.

Conclusion: Finding the Vulnerability Is Not Success — It Is the Beginning

Dozens of vulnerabilities can be found at the end of a pentest or source code analysis.

That is a technically valuable result.

But it is not real success from a security perspective.

Because if the flaw is still in the system, nothing has changed from the attacker's point of view.

Real security value emerges at this point:

The vulnerability was found.

It was verified as real.

The risk level was determined.

It was assigned to the right team.

Its root cause was fixed.

A retest was performed.

And a control was added to prevent the same problem recurring.

The real AppSec life cycle is therefore:

Find → Fix → Verify → Learn → Prevent

An organisation that stops at the find stage finds the same vulnerabilities again every year.

An organisation that moves to the fix stage reduces its current risk.

An organisation that moves to the prevent stage develops its capacity to produce secure software.

That is exactly the goal of a mature Application Security programme.

Not finding more vulnerabilities, but producing fewer of them.

The Next Chapter

The Enterprise Code Security Programme: Secure SDLC and the SecureSys Approach

In the final chapter of our series we will bring all the pieces together under a single enterprise model.

How do the processes we have covered so far:

Secure Coding

SAST

SCA

Secret Scanning

DAST

Pentest

DevSecOps

Remediation

stop being independent security activities?

How is an enterprise Application Security Programme built?

Which security level should be applied to which applications?

How is the security champion model created?

How is code security measured?

How is the Secure SDLC made sustainable?

And most importantly:

How does an organisation move from a one-off source code analysis to a continuous, measurable software security programme?