Red Hat introduced Red Hat Enterprise Linux 9.1and Red Hat Enterprise Linux 8.7.
Mobile app security is broken. For example, in August, Mercator Advisory Group released a study showing that 70% of financial and money management apps fail to meet basic security standards. Another study from March, 2021 found 63% of more than 3,000 popular Android apps contained open source code with known vulnerabilities. It's a dangerous state of affairs for everyone: consumers, developers and publishers.
Consumers haven't yet revolted, but that's only because they can't differentiate between secure and insecure apps. A recent Appdome survey shows that 73% of consumers would stop using a mobile app if it left them unprotected against attack, and 46% would tell their friends to stop using it as well.
Big consumer technology companies know this, which is why Apple is in the midst of a huge push to market its devices, including the iPhone, on how well they protect consumers' privacy and security. There's a big opportunity for app publishers to do the same, by marketing the security of their apps. But to do so, they will need to deliver on their security promises, and with current methodologies, that's going to be almost impossible to accomplish.
Why Traditional Security Approaches Don't Work In Mobile Apps
The problem is that there's a massive mismatch between the way mobile apps are developed and the way developers implement security. Mobile DevOps uses CI/CD tools to automate the development of mobile apps and of their deployment into production. Security, however, is still almost entirely manual, which is very slow. Certainly, many organizations do use SDKs (software development kits) to try to speed the process up, but SDKs still require manual integration and implementation can be complex, especially when it comes to encryption.
The current process typically looks like this:
■ Security recommends security standards
■ Developers manually code some of the security into the app
■ Manual penetration testing and code scans reveal vulnerabilities
■ The app is sent back to developers to fix vulnerabilities, but, in the meantime, new features — and new vulnerabilities — have been added
As a result the app is, at best, delayed, which may cause it to miss a crucial market window, or more commonly it will be released with vulnerabilities. Developer laziness is not the reason most security requirements don't make it into releases — the system and tools used to implement security are simply not up to the task, nor can they match the pace of mobile DevOps.
The way forward is to automate the process of security implementation to achieve mobile DevSecOps. Here are five steps an organization can take to get there.
5 Steps to Achieving Mobile DevSecOps
Step 1: Clear Understanding of the Desired Security Outcome
All teams — developers, security and operations — have to come to an agreement about their expectations for mobile security. It has to be a priority. Many organizations model their requirements based on industry standards such as the Mobile AppSec Verification Standard (MASVS), the TRM Guidelines for Mobile App Security or the OWASP Mobile Top 10 Risks. But whatever standard the organization chooses, everyone needs to fully understand the impact the recommended solution will have on their workflows.
Step 2: Automate Security Implementation
Manually coding security is a titanic task. To speed implementation, organizations should evaluate and take advantage of automated, AI-powered systems that can integrate security into a mobile app. In many cases, these platforms are no-code, eliminating the need for any manual implementation at all.
Step 3: Integrate with Your Existing Workflows
Whatever platform the organization chooses to use, it must be integrated with continuous integration (CI) and continuous delivery (CD) processes to achieve an accelerated mobile app lifecycle. Additionally, the relevant development, security and operation teams should collaborate closely throughout sprints to complete mobile security projects. Through the creation of reusable mobile security templates and models that specify the security features required in each Android and iOS app, organizations can further accelerate security implementation.
Step 4: Instant Verification and Validation of the Desired Security Outcome
The last major roadblock to a successful mobile DevSecOps program is the conflict that can arise during the release meeting. Development teams are under enormous pressure to issue new releases at a rapid pace, and without instant verification and validation that the required security is, indeed, implemented in the app, security concerns can hold up a release. Make sure that verification and validation are automatically conducted and documented to avoid last-minute release hiccups.
Step 5: Budget Certainty (Fixed Cost)
A successful DevSecOps program provides budget certainty and predictability. Ideally, an automated approach will eliminate variable dev and headcount costs, as well as the uncertain outcomes often associated with manual coding of mobile app security.
Mobile apps must become more secure, but achieving this goal will require a different, automated approach that enables DevSecOps. For those organizations that succeed in this journey, however, they will be able to provide customers with a secure product, and with some savvy marketing, organizations that provide a high level of protection will be rewarded in the marketplace.