Securing Speed: Strategies for Optimized Protection

Carta's product security team is of the opinion that it is possible to enhance security and concurrently elevate developer productivity. We will be examining how security and developers interact, the progress we are making at Carta, and proposing a process to foster reliance. Product security teams face the challenge of balancing security and software development. Our purpose is to enhance security at the application level, and serve as supportive partners to development teams. As product security engineers, our chief task is to "Find, Fix, Fortify": discover security vulnerabilities, make sure they are addressed promptly, and strengthen systems in order to stop upcoming problems. Additionally, Carta Engineering puts a major emphasis on taking action and making swift progress. Therefore, our objective is to assist developers in constructing safe and beloved products in an efficient manner. After installing a new set of security scanning tools to our code repositories, our security engineers and developers were presented with a lot of labor that was tedious and time-consuming. Integration with a CI/CD system kept out new vulnerabilities, but it was tough to fix existing vulnerabilities and new CVE's. We had to go through findings, make assessments, create Jira tasks, assign responsibility, send out Slack messages, and keep track of activity. We found that there had to be a simpler method. Our approach is to not just embrace automation for security, but also for development teams. Developers are our "clients," and similar to how they strive to create products that please Carta's clients, we look to create tools that improve the development experience. We work to cultivate a close, cohesive relationship between security engineers and developers. By investing in earning the trust of developers, we can strengthen security and also earn the trust of our customers. The product security team at Carta launched the “Automate to Accelerate” (A2A) initiative to provide an optimized experience for vulnerabilities monitoring to Carta's developers. We have devised a strategy that is comprised of three distinct components. Giving the appropriate priority to security flaws is paramount; this boosts esteem from developers and ensures the problems that demand attention get tackled right away. Every time security software signals a warning, an alert is sent to the security crew through Slack. If the issue proves to be valid, a custom Jira ticket is created with the suitable owner, degree of danger and deadline. By making it easier for security personnel to vet alerts, we have been able to decrease substantially the number of mistaken signals sent to the development teams. In spite of the enhancement, the issue of prioritization has not yet been fully addressed. As an illustration, our Generic Software Composition Analysis (SCA) tool triggers alerts for each installed package with a CVE. Without another layer of filtering, security engineers would become overwhelmed by this. Enter the Exploit Prediction Scoring System (EPSS), which uses machine learning to allocate a numerical score to each CVE to indicate the chance of that vulnerability being used. A2A automation then prioritizes Open Source Software (OSS) vulnerabilities based on this score and the probability of them being exploited. Carta's developers make use of Slack for their building efforts and as such, we need to be aware of the potential issues with unwanted prompts from bots that can divert attention away from their work. To prevent this, our notifications must be able to accomplish two key objectives: As little noise as possible should be made during the course of events. Keeping this idea in view, A2A has a straightforward arrangement of three potential computerized warnings in the timeline of a security weakness: The benefit of these notices is their succinctness, directness, and immediacy. Identifying the correct vulnerability holders is vital to ensuring notifications are useful. To make sure this happens, we created an in-house web tool for organizing Carta Engineering's structure. This includes data on areas, code storage, potential vulnerability owners, and how they're connected. That way, we can make certain that the right people receive the necessary notifications. When we created our A2A initiative, one of our underlying principles was to start by cultivating empathy. This approach fostered trust, which enabled us to build productive relationships. As a result, our actions were more impactful. We built A2A with feedback from developers in the early stages, and included key developers to ensure the messaging behind it was properly conveyed during All-Hands presentations and executive meetings. We focused on how A2A could improve the development experience with Carta, not just its impact on our security measures. We make it easy for development teams to request deadline extensions for bugs in Slack, and the security team evaluates each request to determine if the risk posed is acceptable. Escalation is limited to the absolute necessary cases. Our success with A2A is judged taking into account both vulnerability engagement metrics and developer satisfaction. We monitor one metric, which is how long an issue remains on the Jira board until it is being actioned. This is referred to as "staleness". Our goal is to make sure that plans are set up expediently, notwithstanding the fact that their implementation may be deferred for several weeks contingent on its level of significance and effect. This guarantees that we make rational choices when it comes to product safety and product improvement. What has been the result of A2A being rolled out? Security issues have been attended to in one-third the time they used to take, which means that they now become stale 3x slower. We have witnessed a remarkable rise in the number of vulnerabilities that are dealt with promptly. To conclude, developers were questioned about their familiarity with vulnerability management at Carta. The results look good. So far A2A has met with favourable reviews and there is no evidence that vulnerability management has got harder for developers. This is a major success since usually security upgrades come with a downside of lower productivity for developers. If our A2A vision is to construct a car, then what we currently possess is a bicycle. Our plan to release a motorcycle appears thusly: The product security team at Carta believe that velocoty and security can both be achieved. We endeavour to support developers while being firm on our security principles. By working to understand developers' difficulties and demonstrating our desire to help them build secure products quickly, while using technology and inventiveness to provide solutions that made a difference, we can develop trust between the development teams, our customers and ourselves. Trust is a necessity for Carta to continue to grow, and it is the security team's mission to help create that trust.

Source: https://medium.com/building-carta/fast-and-fortified-how-to-build-for-security-and-speed-5ffad964f28a?source=rss------fintech-5