34

I work as the team lead of the IT Security team where I work. A major part of my job duties is leading vulnerabilities scanning, management, and remediation validation. I frequently interact with other teams, with significant amount of interaction with development teams and QA.

Yesterday, I was working together with our QA team to validate business requirements before application changes were released to our production environment. One of the security requirements is that certain security controls be implemented into the code to mitigate a basic set of vulnerabilities (think OWASP Top 10 for example), but as security was not involved early enough in the requirements gathering / story design phase prior to development, this requirement was not clearly captured in the user story.

Through testing results from tools such as SonarQube and Burp Suite, security requirements were not met. Multiple vulnerabilities still remain exploitable and tools to exploit these are freely available. As a result of the security requirements not being captured in user story, I anticipate push back from development that this is not a fair request. Starting a new feature request would take much more time and would most likely jeopardize timely release, with business stakeholders (non IT) who are using this software being unhappy. Both my team, QA, and my manager agree that this is a critical issue that should be fixed prior to release. If this vulnerability is exploited, sensitive customer data could be leaked. I am still researching to see if the vulnerability is in the wild at this time.

How do I communicate to the development team that the security vulnerability must be fixed before release, while acknowledging that this request is not exactly within the scope of original user story? I want to avoid undue delay in remediation and not escalate if I don't absolutely have to.

Improve this question
10
  • 6
    I’m voting to close this question because this seems like a process issue more than anything else. The most appropriate option will heavily depend on how things work in your company and what development methodology you use. Maybe you need to create a ticket, raise it during a meeting, host a meeting, send it in an email or discuss it with the PM. Do you know how issues are typically reported or discussed or have you asked your manager or someone on the dev team what the process is? – Bernhard Barker Apr 29 '20 at 13:37
  • 4
    This definitely sounds like a process issue. I may be reading between the lines here, but it sounds like the real problem OP is trying to address is how to assign blame within his company's development process. The developers will apparently refuse blame if they fulfilled the requirements as written, and will want the parties responsible for creating requirements blamed; OP doesn't want to blame those other parties, and opening a new feature request will do so implicitly. – tbrookside Apr 29 '20 at 20:25
  • 66
    Shouldn't "feature does not introduce exploitable bugs" be an implicit assumption in every single user story? I've never seen that mentioned explicitly anywhere. – Voo Apr 29 '20 at 20:33
  • 3
    This is obviously a screwup of the project management. Seems more like a problem for pm.stackexchange.com – Philipp Apr 30 '20 at 11:26
  • 6
    Why not just talk to the PO about adding a new User Story to the list? "As a user, I don't want my personal information leaked as a result of [security vulnerability]" The whole point of Agile is to make it possible for the dev team to change their work in accordance with new requirements. – nick012000 Apr 30 '20 at 14:49
9

this requirement was not clearly captured in the user story.

sensitive customer data could be leaked.

The keyword in user story is user.

The explicit points written up in the story, typically new functionality, are merely a subset of what's required to ship. It's also implicitly required to maintain the entire current state of things the user wants. This obviously includes not leaking their sensitive data.

No user story is shippable if it introduces something actively harmful to the user, period. No matter what other new functionality it enables.

That said, pragmatic advice on what to do here:

  1. Go directly to the dev team, find out who's working on the story and tell them about the vulnerability - the goal being to ascertain if they clearly understand that the story can't be shipped until that's addressed. If that's the case, job done.

—— OR ——

  1. If that doesn't work, perhaps due to dysfunction within the dev team and/or the organisation's implementation of its agile process, then work with the dysfunction rather than against it.

    Every agile process has its 'escape hatches', essentially for subverting the process for stuff that absolutely must be done right now. In some it's someone with a certain job title tapping you on the shoulder, other's it's a P0 bug ticket, etc. Find out what it is in your organisation, and do that. If you don't have the authority, you have no choice but to escalate.

Think of the user! Your organisation will thank you (eventually!)

Improve this answer
1
  • Yes, circumvent all managers (including he project manager), as well as all the processes and best practices, and you are on the sure way to a promotion :) The best engineering is done by word of mouth, right? Documentation is for losers. – virolino May 18 '20 at 6:25
87

The way you describe it, you found the vulnerability more by intuitive testing, rather than by test-cases-based testing. That is a very good and valid way of testing. The end customers definitely use the software without any requirements or test-specification document.

Now, the way I see it, you do not "communicate to development team" anything. You just fill in the issue report (bug) in the issues management system, and notify the project manager that a high impact problem was found. It is in the authority and responsibility of the project manager to decide what to do with the issue - fix, not fix, delay fixing.

To be sure that you are covered in case of future problems, if the bug is not fixed, be sure that you have written communication with the persons involved (using dedicated tools, like the issues management system; or even e-mail).

is not exactly within the scope of original user story

Site security and data safety are the first "user stories" of the project - the way I see it. The "user" is the business, which prefers to remain in the market, without scandals about data leakage. Everything else comes after. And exact words do not matter.

Improve this answer
4
  • 35
    I have had success with the concept of "evil-user" stories, where the user (Mallory, Eve, or whoever) tries to do something, and the AC include "this does not work" and error messages/reporting. – chrylis -cautiouslyoptimistic- Apr 29 '20 at 13:24
  • 7
    That sir is an elegant and fail-proof way to work professionally while raising concerns without interfering with implicit and perhaps undiscovered work culture: "Just use the established channel, even for exceptions". That allows to set aside the assumptions about the reason for the (subjectively) bad implementation and focus on the artifact itself. – NextThursday Apr 29 '20 at 15:20
  • 4
    For Facebook, Zoom & others it seems that scandals about data leakage are just a form of free advertising. – ojs Apr 30 '20 at 7:17
  • 9
    Security and data safety are Non Functional Requirements that should be taken care of in every story, not a bunch of stories that you take care of once for good. – Laurent S. Apr 30 '20 at 12:27
57

but as security was not involved early enough in the requirements gathering / story design phase prior to development, this requirement was not clearly captured in the user story.

That thinking is a huge red flag. I am a developer and basic security is implied when I deliver a product. That should not need to be in a user story. If I buy a car, I don't pick make, model and explosive radius and if I don't say anything about the latter the manufacturer gets to pick what they like best. My car is not to explode, period. That is implied when I say I want to buy a car.

If you don't have basic security guidelines all of your developers adhere to without spelling them out every time, you need some. Yesterday. But again... faulty security is a faulty product, just like random crashes or being unacceptably slow. Developers should know this. It's not an afterthought it's their job. A developer that does not know about basic security should not develop software, they should learn to develop software.

What you should do is first talk to the developer in the hallway. Tell them what you found, ask them to change it. Ask them how they would like this requirement captured in the future. Ask them if they need help arguing with whoever is in charge of timelines why this needs to be fixed first. The developer(s) probably know the details and they know how long it will take. They know whether this is actually critical issue or maybe just a configuration mistake in your QA environment. When you know what needs to be done, file a ticket with whatever you agreed on and inform the project management. This should help the developer and yourself to avoid unnecessary Chinese whisper games where everybody in the project is talking about the ticket, except the two people who could actually solve the problem.

If the developers don't comply, file a critical bug in your system, just as you would if you notice something very wrong that wasn't spelled out in the requirements. I'm sure there are "cancel" and "back" buttons and nobody spelled it out that they should indeed go back or cancel instead of crash the application. So it's not like you cannot have a bug without spelled out requirements.

Improve this answer
11
  • 18
    I mostly agree, except for the "hallway talk". I would advise filing the critical bug now, to make sure that all parties involved (including Project Manager, Team Leads, etc...) are aware that a delay may be coming. – Matthieu M. Apr 29 '20 at 14:40
  • 8
    You do not get security through just having developers following "basic security guidelines" - that is not a reliable way to fix the problems of an architecture that is insecure by design. While one might normally start developing user stories without being rigorous about security, the results need reviewing for security issues at some point before they become frozen. Story design is not security-neutral, and the implication that any story can be implemented in a secure fashion is false. – sdenham Apr 29 '20 at 17:03
  • 2
    @MatthieuM. Not sure how long your hallways are, but I was thinking more about 30 minutes to maybe an hour if the developer is in a meeting to give them a little heads up and maybe get better information on what needs to change before the ticket is written. I hate it when someone raises all hell with the brass coming running to my desk with weird, half understood questions, when person-to-person technical talk could have solved it or at least made a better problem description in less time than I need to get rid of all the *-managers to be able to work. I don't think it's "30 minutes" critical. – nvoigt Apr 30 '20 at 10:26
  • 2
    @sdenham You seem to imply that "software development" is only coding and architecture is some other external force that happened prior to that. Design is a part of software development, so obviously guidelines should help with the design as well. Obviously the story "As a user I want to login without authentication to save time" is not going to be secure, ever. But I don't think that this is what we are talking about here. – nvoigt Apr 30 '20 at 10:34
  • 2
    @nvoigt: I see... that's not at all how I understood your answer. I thought your answer ("Tell them what you found, ask them to change it") was about circumventing the process. I do agree that asking more details out of the developer with raising a bug seems worthwhile, but that's a completely different thing from what you wrote in your answer. – Matthieu M. Apr 30 '20 at 11:55
13

I do want to generalise a little here, and move away from security consideration specifically.

When companies do work, they don't do it in a vacuum. The company uses the culture of its employees. It uses lessons from previous products and customers. It uses best practices of the industries it operates in.

As such, I'd argue there are implied user-stories that a tethered to the ethos of a company. Such implied user-stories exist (and should exist) in the mind of every developer.

It is healthy for a developer to go: "I am satisfying this use-case... but we don't usually do things this way. I better check with the PM that this is what's meant." This is similar to the situation where two use-cases are in conflict.

Following regimented development practices assumes people don't make mistakes. People do make mistakes, such as forgetting to include important requirements. It's worth noting that following regimented development practices can also help guard against mistakes. But you don't march yourself off a cliff because that's what the map says to do.

I can think of several implied requirements that often exist, usually without being explicitly specified. Often the product must:

  • Comply with legal requirements
  • Comply with licencing agreements / contracts
  • Not be horribly cost ineffective
  • Not bring the company into disrepute
  • Not perform in ways that endangers lives

There may be situations where some of the above are deliberately violated, but that must come about by deliberate decision, not forgotten user story.

As for what you should do. You file a ticket.

Improve this answer
3

There is no general solution.

Short term

  • Talk to the project manager, develop team, or scrum master. You should address your concerns and ask them to fix them before release. If it does not work out, you should involve your boss maybe their boss, too. Depends on your relationship.
  • You could open a bug. If the severity is high enough, they might not be allowed to ship the version of your software. But this might made the developers angry.

Further down the road:

  • You should either write / request security related stories.
  • Ask the project to modify the definition of done. Many security tests can be integration in automated testing / CI/CD pipelines. A story is only done, when all tests including security tests passed.
Improve this answer
1
  • 1
    What about talking with the Product Owner? – ChrisFNZ May 1 '20 at 22:16
3

The user stories document Functional Requirements - that is what the system is required to do, what functions it needs, what end users expect to be able to achieve etc.

There is another set of requirements about basic things that users don't think about until something goes wrong, these are called Non Functional Requirements and covers such things as is the system secure, is it stable, is it backed up, is it easy to maintain etc.

Non functional requirements don't need user stories but do need to be met before a system can go live. It's better if these documented and understood up front but you still have the right to report that this system has failed a critical check and needs to be fixed before progressing to live.

Improve this answer
2

Your role is to alert on security issues, or potential security issues. They can be discovered during the design (architectural mistakes for instance), or during development (incorrect or non-existent SDLC), or later. There are of course better and worse moments to discover a vulnerability, but it is always best to discover it in the first place (before someone discovers it for you).

Since you role is to alert, you should target the people who make decisions about this product. Ultimately this may be the CEO.

Having all the information you provide (kind of issue, probable or possible impact, ideally a probability (but this does not exist in the real world)), they will make a decision, based on that risk analysis.

They may accept it, fix it or have an insurance. This is not your problem, though. Your role is to alert (and provide substance to make a decision).

Depending on the company, you may have the power to make such decision (= a no-go for the release), but from your description it seems that this is not the case.

Improve this answer
0

Does this have a Dollar($$$$) value for non-compliance or failure or data release or exploitation. If it is 'important' then it will gave a proper business value.

While bug reports and requirements are a normal part of the development process, in the grand scheme of things they aren't 'that important'. That is, many requirements are ignored, some have mission creep. Bugs are miss classified. You will have seen all this happening to other peoples issues.

If this is a tick box exercise then you will not succeed. If you identify the business value and risk then you can work with the risk management and contingency planning process to deliver real benefit.

Improve this answer
0

If you have control over the requirements, just add these bugfixes to the requirements. Keep in mind that prioritization issues might arise.

If you have authority over the developers, just command them to work on this (in professional terms, obviously).

If you have control over the release, just add this requirement to the release.

If you have no control over the requirements, no authority over the developers and can't gate the release, then you don't get to the developers what their job is. It's just not your place. What you need to do is make fixing this their job, by talking to the people who can actually tell the developers what their job is.

You need to block this release, so talk to the release manager or whoever controls releases. You need to add this to the requirements, so talk to the product owner, product manager, project manager or whoever defines the requirements. You need to make this work a priority, so talk to the product owner, product manager, project manager or whoever prioritizes the requirements.

Additionally, I suggest communicating to the developers in a direct or indirect but very clear way that you are (or someone from your team is) available for any questions they might have about security, both for these issues and for future issues. Keep in mind developers will surely not know as much about security as the leader of security yourself, and they might not even know what OWASP is. Security training might be a great idea for the future.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .