Last week I had the pleasure to host an interactive session with Jim Manico, one of the world leaders in application security, to discuss the importance of developers adopting secure coding standards from the very beginning of the SDLC.
The goal of the session was to review some of the reasons why the reliance on bolt-in security (such as external defenses and cloud firewalls) is not enough and to present some resources and best practices to help developers adopting security from the first day.
A recording of the session is available below, and we will also list the links to the resources presented during the conversation.
AppSec resources shared during the session
Offensive security projects:
- What WAF: web application firewall detection tool (recon and intelligence gathering) and collection of bypasses.
- Awesome WAF: web application firewall resources including architecture, vendors, and known bypasses.
- Cloud WAF Comparison Using Real-World Attacks: Tuomo Makkonen research on the effectiveness of cloud WAFs to stop and block common application attacks.
Secure development resources and controls:
- OWASP Cheat Sheet series: a concise collection of high-value information on specific application security topics.
- OWASP ASVS: list of web application technical security controls, which can be used as requirements for secure development.
- BORNSECURE What is Server Side Request Forgery: detailed overview of the risk demonstrated during the interactive session.
- Insecure Bank: a deliberately insecure open-source web application to demonstrate many types of security vulnerabilities.
Security tooling and automation:
- Hdiv Detection IAST Developer Toolbar: fill the form if you would like to test run the developer toolbar in your own environment and find security vulnerabilities
Questions & Answers
In my company we are using a tool to detect security bugs, more specifically by our developers. We scan the code and we have a report with existing bugs. The tool shown is the same? Does it scan the source code statically? Could you clarify this point?
The family of tools that look at the source code statically to find security vulnerabilities is called SAST (static automated security testing). The goal of SAST tools and IAST tools is the same, to find security vulnerabilities in the applications so that developers can fix them before they are exploited. However, the technology behind the two families of tools is very different. Static analysis looks at the raw source code looking for patterns. Interactive AST works during runtime to understand how the application really works. According to scientific tests, Interactive AST finds many more types of vulnerabilities with fewer false positives. Read everything about IAST here.
What can possibly be the difference between a secure code and a non-secured code?
Secure code does not security vulnerabilities nor design flaws that can be exploited to compromise the application.
For Manico: Is ASVS a good standard for Web Application Security Auditing?
Yes, absolutely, indeed the original goal of the ASVS is to facilitate the verification of applications, as the initials mean Application Security Verification Standard.
What about managers? Do you have experience in involving Managing in this? Is it useful to involve them?
We recommend all teams involved in the SDLC to participate in the security. When it comes to secure budget, the ROI of AppSec is normally very high, when compared to the cost of a security breach.
Can we integrate Hdiv in Spring Boot application?
Yes, absolutely! In fact, Pivotal recommends Hdiv as a security integration for Spring and Spring Boot applications. Reach out to us if you want to know more.
Can we properly integrate hdiv to GitLab CI and which experience is better, IAST / DAST or both?
Hdiv Detection (IAST) works during runtime, so it needs an application server to perform the security analysis. However, it is easy to automate the inclusion of the Hdiv agent in an automated testing environment. Hdiv supports Jenkins natively and we are working on new integrations. Reach out to us if you want to know more.