A security finding lands in the development team's backlog.
The finding says an application exposes sensitive customer information to users who shouldn't have access to it.
The developer investigates the behavior, reviews the requirements, and confirms that the application is functioning exactly as specified.
The response is straightforward:
"This isn't a bug. The application is working as designed."
Technically, that may be true.
But it doesn't necessarily resolve the security finding.
The application might satisfy its functional requirements while still introducing an unacceptable security risk.
This is where development, security, and governance teams can find themselves talking past one another.
Let's walk through a practical example and examine how to evaluate the finding without turning the discussion into an argument over who is right.
The Scenario: A Customer Export Feature
Imagine a fictional customer management application used by an internal support team.
The application allows authorized employees to export customer records as CSV files.
The feature was requested by the business, implemented by developers, tested by QA, and released successfully.
A simplified API endpoint might look like this:
GET /api/customers/export?region=southeast
Authorization: Bearer <access-token>
The intended behavior is straightforward:
- An authenticated employee requests an export.
- The application retrieves matching customer records.
- The application generates a CSV file.
- The employee downloads the file.
During a security review, an analyst discovers that employees with general support access can export fields that may not be necessary for their role.
The export includes more customer information than some users need to perform their jobs.
Security raises a finding.
Engineering reviews the ticket and points out that the feature was implemented according to the original requirements.
Both teams have identified something important.
Engineering has confirmed the application is behaving as specified.
Security has identified a potential authorization and data-exposure problem.
Neither observation, by itself, determines whether the risk is acceptable.
Step 1: Separate Functional Correctness From Security Correctness
The first mistake is treating functional correctness as proof of security.
A feature can pass its functional tests and still violate security requirements.
For example:
| Question | Functional perspective | Security perspective |
|---|---|---|
| Can the user export data? | Yes | Should this user be able to? |
| Does the export contain the expected fields? | Yes | Are all those fields necessary? |
| Does the endpoint return successfully? | Yes | Is access restricted appropriately? |
| Does the feature meet the specification? | Yes | Does the specification address the relevant threats? |
These are different dimensions of quality.
A successful functional test establishes that the application behaves as expected under the tested conditions.
It does not automatically establish that the behavior is secure.
The same principle applies to security tooling.
A scanner finding isn't automatically a complete risk assessment. It is evidence that needs to be evaluated in context.
The goal is to establish what the system actually does, what it should be allowed to do, and whether the difference creates meaningful exposure.
Step 2: Identify the Security Requirement
Before deciding whether the finding is valid, identify the requirement it may violate.
For the export feature, relevant requirements might include:
- Users may access only the customer records authorized for their roles.
- Exported information must be limited to fields necessary for the business function.
- Sensitive data exports must be logged.
- Access decisions must be enforced on the server.
- Privileged export capabilities must be explicitly authorized.
These are illustrative requirements, not a universal policy.
The organization's actual policies, data classifications, contractual obligations, and system architecture determine what applies.
This distinction matters because a finding should not depend entirely on someone's personal interpretation of what secure behavior looks like.
There should be a clear connection between the observed behavior and the requirement being evaluated.
Step 3: Validate the Behavior
The next step is to establish whether the reported behavior can be reproduced.
For the fictional export endpoint, a useful test matrix might look like this:
| Test case | Expected result |
|---|---|
| Unauthenticated request | Denied |
| Authenticated user without export permission | Denied |
| Authorized support user exporting permitted fields | Allowed |
| Support user requesting restricted fields | Denied or restricted |
| Authorized administrator exporting approved fields | Allowed |
| Export request | Appropriate audit event recorded |
This is where collaboration between security and engineering becomes valuable.
Engineering understands the intended behavior and system architecture.
Security can help identify misuse scenarios and access boundaries that may not have been included in the original functional tests.
Together, the teams can determine whether the implementation enforces the required protections.
For example, hiding an export button in the user interface is not sufficient authorization if the backend endpoint still allows an unauthorized request.
The authorization decision must be enforced by a trusted component.
Step 4: Evaluate the Actual Risk
Once the behavior is understood, evaluate the exposure.
The same technical issue may have different consequences depending on the environment.
Consider:
Who can access the feature?
Is the endpoint available to every authenticated employee, a restricted group, or only administrators?
What information can be exported?
Does it include ordinary operational records, sensitive personal information, or other restricted data?
What limits the exposure?
Are there effective role restrictions, field-level controls, monitoring, export limits, or other safeguards?
What could happen if access were misused?
Could an unauthorized employee retrieve records outside their assigned scope? Could a compromised account extract large amounts of information?
What evidence supports the assessment?
Are the conclusions based on verified authorization tests, application configuration, logs, and documented requirements?
This is more useful than arguing over whether the finding deserves a particular severity label before its context is understood.
The purpose of the assessment is to support an informed decision about what needs to happen next.
Step 5: Compare Remediation Options
Not every valid security finding requires the same technical solution.
For the export feature, possible remediation options could include:
Option A: Restrict export permissions
Limit the export endpoint to roles with a documented business need.
Option B: Apply field-level authorization
Allow users to export only fields permitted for their roles.
Option C: Reduce the data returned
Remove unnecessary sensitive fields from the export entirely.
Option D: Strengthen monitoring and safeguards
Add appropriate logging, anomaly detection, export limits, or additional approval controls where justified.
These options are not interchangeable. Logging, for example, does not replace authorization.
The right solution depends on the requirements, the architecture, and the risks being addressed.
Engineering should be involved in evaluating implementation feasibility, dependencies, and potential unintended consequences.
Security should verify that the proposed remediation actually addresses the identified exposure.
And if residual risk remains, the organization needs an appropriate decision process for handling it.
Step 6: Understand What a Risk Acceptance Actually Means
Sometimes a team cannot remediate a finding immediately.
There may be operational dependencies, architectural limitations, or a planned replacement.
That doesn't automatically make the risk acceptable.
A formal risk acceptance should identify the exposure, supporting evidence, accountable owner, decision authority, duration, and any required conditions or compensating controls.
It should also be revisited when relevant circumstances change.
Closing a development ticket isn't necessarily the same as remediating a security finding.
And obtaining an approval isn't necessarily proof that a control is operating effectively.
The distinction matters because the organization needs to know whether a risk was eliminated, reduced, transferred, or formally accepted.
Step 7: Make the Outcome Verifiable
This is where I believe software engineering principles can improve governance.
A security finding should not end with an ambiguous status such as "done" when nobody can establish what changed or whether the requirement is satisfied.
Where practical, the remediation should have verifiable acceptance criteria.
For example:
Feature: Customer export authorization
Scenario: Unauthorized user requests an export
Given a user without customer export permission
When the user requests a customer CSV export
Then the request is denied
And no customer export file is returned
Scenario: Authorized user requests an export
Given a user with approved export permission
When the user requests a customer CSV export
Then only permitted records and fields are returned
And the export activity is recorded
These scenarios are simplified examples. Production tests would need to cover additional conditions, including authorization boundaries, data sensitivity, error handling, and relevant misuse cases.
But they demonstrate an important idea.
The outcome is no longer based solely on whether someone says the issue was fixed.
There is a defined behavior that can be tested.
A governance process can then connect the requirement, implementation change, test result, evidence, and final decision.
This is closely related to the work I've been exploring through Governance as Code: applying engineering concepts such as traceability, version control, and structured verification to governance processes themselves.
The objective isn't to automate away human judgment.
It's to make the technical evidence supporting governance decisions more reliable.
What Developers and Security Teams Should Take Away
When someone says a system is working as designed, the response shouldn't automatically be to dismiss the finding or demand an immediate redesign.
Start by understanding what the system was designed to do.
Then evaluate whether that behavior satisfies the applicable security requirements.
A productive review should establish:
- The observed behavior.
- The intended functionality.
- The applicable security requirement.
- The conditions under which the behavior creates risk.
- The available remediation options.
- The accountable decision-maker.
- The evidence needed to verify the outcome.
That gives both teams a shared problem to solve.
Developers shouldn't have to defend a design without understanding the security concern.
Security teams shouldn't have to rely on a severity label without explaining the exposure.
And governance shouldn't be reduced to recording a decision after the technical conversation is over.
Working as designed tells us whether the implementation matches the specification.
Working securely requires us to examine whether the specification, implementation, and operating conditions adequately address the risk.
Those are different questions.
Good security engineering needs both.
From the Conference Stage
I explored the relationship between security findings, developer perspectives, and governance decisions in my Carolina Code Conference 2026 presentation:
When Security Says "High Risk" and Developers Say "But That's How It's Supposed to Work."
Watch the full conference presentation on YouTube
For a broader discussion of the organizational side of these disagreements, see my companion article on Medium.
I also explore the engineering of governance processes in my ISACA article:
Governance as Code: Applying Software Engineering Principles to GRC Program Design
Neviar Rawlinson is a technology governance and risk leader, speaker, and founder of GRC Explained. Her work focuses on connecting governance, cybersecurity, risk management, and practical technology implementation.
Top comments (0)