Industry: E-Commerce
Company: Ödeal
Location: Türkiye
Product: Invicti ASPM
Ödeal’s Story of Building an AppSec Program.
Challenges
- Ödeal had a problem where security was not built into the software development lifecycle (SDLC). Tools were used by development teams at will.
- Penetration tests conducted quarterly put pressure on development teams as vulnerability remediation interfered with their activities.
- There was no visibility into application vulnerabilities, as well as monitoring of security metrics.
About Ödeal
Founded in 2014, Ödeal is a payment technology provider that allows businesses to accept debit or credit card payments using mobile phones. With over 68,000 customers and a solid business model, the company secured funding in 2021 and has been rapidly expanding its technology teams ever since.
Situation
As a fast-growing fintech startup, as was their technical team, Ödeal was in the process of restructuring their CI/CD processes.
Due to the nature of the business, security was a concern for management, but with so many developer tasks, it was hardly possible to allocate time to create a CI/CD pipeline integrated with security tools.
There was a need for a platform where security tests could be easily integrated with CI/CD pipelines, which could also provide visibility into the overall security state of the applications.
Invicti ASPM Approach
- As a first step, applications existing in the CI/CD tool were automatically uploaded to Invicti ASPM after integration in a matter of minutes.
- Based on the technology stack used in each application, the appropriate open source security tools were configured in Invicti ASPM.
- Since Ödeal already had a git-flow branching mechanism, security tests were located between feature and development branches so that Invicti ASPM could run scans with open source security tools on every pull request.
- The company-wide script was that if a repository was recently created in a CI/CD tool but not yet in Invicti ASPM, it was automatically created via the CLI based on the hierarchy used by software development teams.
- Using the label-based automation capabilities in Invicti ASPM, different automation policies were applied to applications with different labels (i.e. internal, external, GDPR).
- The functionality of adding security test results directly to the pull request allowed developers to access vulnerabilities found in every pull request in their CI/CD tool so that they were aware of the vulnerabilities before moving on to further stages of the pipeline.
Results
- Without spending a lot on commercial tools and without even having an in-house security team, the technical aspect of the DevSecOps transition was easily achieved by writing a company-wide pipeline script that is used across all applications.
- This means that any team that migrates to a new CI/CD pipeline now automatically integrates their projects into Invicti ASPM and starts running predefined security tests within the pipelines themselves.
- In the absence of a security team, label-based automation rules performed basic threat modeling activities across development teams, leading to increased awareness of application risk perceptions. This approach also helped focus attention on vulnerabilities that were most likely to pose a real threat, without creating noise for development teams.
