Development and security usually just don’t talk the same language. Security specialists believe development is rushed to deliver applications without proper security. Developers believe security specialists are overcomplicating things and slowing everybody down.
We see it as our mission to bridge that gap, and have everybody get along and work together towards the common goal of delivering good, secure apps at a quick pace.
To get developers’ attention and have them not hate the process, code security needs to be delivered in a way that does not interfere with existing goals and workload. This is relevant especially in agile environments, but also in traditional waterfall organizations.
With Seeker, code security becomes part of the development and testing process by integrating into existing frameworks (for example – security tests launched from continuous integration servers, working with automation frameworks like Selenium, delivering results into bug tracking systems like JIRA or TFS).
Seeker delivers security testing results in plain English, with the user not requiring security knowledge. It provides simple descriptions, such as “an attacker can steal information from the database” or “an attacker can hit users with malware or Trojans by uploading malicious files to the server accompanied by screenshots and videos of simulated attacks. These results are easy to understand.
The process of verification and generating a simulated attack allows Seeker to evaluate and demonstrate risk. There is no doubt, no need for triage. If it can be verified and exploited – it is most definitely real. This means that developers don’t waste their time on invalid bugs (one of the nastiest time burners in development).
Developers love (or at least don’t hate) Seeker because of the following reasons:
This post is also available in: French