Dennis, Principal Security Consultant (Veracode) asked a question.
Hello Community!
Community Members @Boy, Security Consultant (Veracode) and @Dennis, Principal Security Consultant (Veracode) of the Application Security Consultants here! We’re excited to host a new series for Tips Tuesday, “Secure Application Development,” from July through August.
We will kick off this series with “Security Horrors.” As developers ourselves, we understand the many reasons -- limited budget, unrealistic timeline, etc -- that led developers to “game” the programming to pass security scanning or apply a fix that does not address the actual problem. Over the years, we’ve learned that many of those attempts trying to satisfy the scanner ends up putting one’s organization at more risk or having to spend even more time trying to “pass” than what it would have taken to address the problem.
What was your experience with security horrors?
- What poor controls have you seen folks implement for “security”?
- What have you seen implemented to just “pass” the security test?
- How do you prevent or overcome “security horrors” in your software development program, either as a developer or a security practitioner?
🔖 Related Reads
“Copying code from Stack Overflow? You might paste security vulnerabilities, too” from Stack Overflow
Key takeaway: “The code snippets posted as examples are not production-ready code. Don’t copy this into a project without understanding the code and testing it.”
“Dumb password rules” from GitHub
Key takeaway: A list of questionable restrictions placed on passwords
“The Most Secure Option" from the DailyWTF
Key takeaways: Security trade-offs
.png){kind=logo}
One behavior that I've seen over and over is the rush to tag a vulnerability as a "false positive" mitigation and provide some nonsense reason why they can't or won't fix it. In 99% of the cases, there's no false positive at all - it's simply a misunderstanding of how static scanning works. When developers are able to understand that vulnerabilities are primarily an instance where tainted data reached a sink, they begin to behave differently and actually look for failures to sanitize, encode, or constrain data that's input to the application. They begin developing reusable code for themselves and the other teams, and provide an incubator for possible custom cleansers that significantly clean up scans quickly and efficiently.
Excellent contribution @Mark_M (Community Member), and indeed Veracode finds very few false positives (the industry leader in that regard), though from my experience the mitigations are not always nonsense. For example, I regularly see mitigation proposals stating that a component is third party. On the face of it I can understand why this may be so: a developer has deadlines to meet and they need to fix the issues in their product, so the focus is only on making the changes they can control. However, if the developer took a step back from the daily backlog and looked at what we're trying to achieve with security scanning from a higher level, they would see that whilst the third party components are outside their control, a third-party flaw could impact their application, which could directly affect their organisation and their customer's data. Usually it's just a case of updating to the latest version or reaching out to the security team to co-ordinate remediation efforts with another team.
I do also see from time to time nonsense, incorrect or misleading mitigations proposed whilst carrying out a Mitigation Proposal Review (MPR) (see https://www.veracode.com/resources/customers/wklympr). In this capacity Veracode is acting as a trusted adviser to our customers, where they may not have the technical appsec resources to process and validate the mitigations proposed. As the developer cannot pull the wool over my eyes so to speak, I would use the opportunity to educate them of the importance of correctly resolving the issue or accurately describing the mitigating controls in place.
Agreed on the false positive part- its a struggle sometimes to encourage teams to not jump to that button as a solution to their problems. We are trying to curb that by having the team lead attest and approve the proposal is accurate (effectively taking the risk on their own shoulders). We also try to encourage teams to meet with Veracode via a consultation to verify with a trusted third party that it may indeed be a false positive or cant be exploited.
@ABacchi035478 (Community Member) do you find that ownership route is working out favourably? I'd be interested to hear the impact this approach has had.
It sounds like you're heavily involved in the management of your appsec programme, and I wonder if you have a security horror story you might want to share (one that is safe for all to see and not naming names to protect the innocent/guilty of course!)?
Not scanning or including all modules. If a full site static scan returns 100%, in under a minute, there is a pretty good likelihood something isn't quite right. 🙂 It is an opportunity to work with the security champion or engineer to help educate and provide assistance. If there are no flaws to view, then review the configuration to validate that everything is configured properly. If it's a legit 100%, then that's a well deserved fist pump to celebrate your success!
Another one came to mind. For Dynamic scans, not selecting authenticated scans for a website that is 99.9% behind a login page. "Great, your login page doesn't have any flaws" but what about the rest of the site?" 😮
So true, and far too easy to do when setting up the scan, and then you think the app's covered but in reality it's not.
I can’t resist…one of my first engagements was with a team using a custom XSS web filter which would pattern match against payloads from previous pen tests/DAST findings and 404 the request. Every new finding would leave to another proof of concept pattern match added to the filter as a “fix”.
Application security education is still a challenge, so I give teams the benefit of the doubt before declaring out right cheating. A quick tutorial in why a deny list is a losing battle and how to use output encoding, we were able to get the flaws resolved correctly. And oh boy, did they get a shock when a member of the security team was reviewing their pull requests!
As far as preventing these horrors, getting involved with pull requests for security fixes allows for moments of collaboration between security teams and developers, fast feedback and spotting a few gems 😉