Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Testing applications is necessary, as bugs and other security vulnerabilities are always found in applications. Many developers have to work under tight schedules; therefore, they don’t always have enough time to test the applications, which often becomes a disaster.
The report late last year from FireEye of a state-sponsored attack targeting SolarWinds’ Orion software sent a shockwave through the industry and the reverberations from the discovery are continuing to ripple. As many as 18,000 SolarWinds customers — including at least nine U.S. government agencies — were infected via the SunBurst breach of the network monitoring and management solution. Moreover, according to a recent study from IronNet, the average financial impact of that attack was 11% of annual revenue or about $12 million per company.
U.S. intelligence has put the blame for the attack on Russian-sponsored hackers, who compromised multiple Orion software updates that were released between March and June 2020, giving bad actors a backdoor into exploited systems. Our research found that the Orion software build and code-signing infrastructure was compromised, with the source code of the affected library directly modified to include malicious backdoor code that was compiled, signed, and delivered via the existing patch release management system.
Editor's Note: The following is an article written for and published in DZone's 2021 Application Security Trend Report.
In today’s technology landscape, organizations are supported by web applications that act as essential enablers to streamlining operations. While these applications enable automation, wider collaboration, and ease of sharing data, they also act as vectors that are prone to malicious attacks. Besides this, as modern applications rely on loosely connected components and services in constant communication, security becomes a complex, time-consuming challenge.
The financial services industry has seen a prolific rise in the use of applications in the last couple of years. Globally millions of customers already use a wide range of mobile app services, and it is estimated that the financial application industry will grow at a rate of 30% in the coming years.
In 2020 there were 26% more mobile app sessions as compared to 2019. Using applications for different financial and banking services is a rapid and convenient way to effectively manage your monetary resources like checking balance, transferring funds, paying bills, and so on.
In part one of this two-part series, we dug into a few urban myths about the security of open source code and trusting your favorite developer tools. While the myths are common, the reality is clear: taking ownership over your code with the right tools and methodologies means you’re creating applications that carry far less risk than ever before. Keep reading for three more common urban myths about secure coding—and how to go about changing them.
Reality: While it might seem like it’s adding extra work on the surface, having more than one testing type embedded into your development process saves time as you’re able to catch more flaws before the production stage. That means you won’t have to remediate a pile of vulnerabilities later on when it’s more of a hassle, and you'll have peace of mind knowing your code is more likely to pass policy checks.
While DevOps is forging boldly into the future, security is still trailing those advances in many organizations. So it’s important that we understand how to apply notions of (traditionally static) security into environments that are built to foster continuous development. I, for one, would like to raise the torch to the fledgling category of DevSecOps and learn how it is successfully implemented by industry leaders. In the first of a series of interviews with DevSecOps community leaders, I chat with DJ Schleen, DevSecOps Advocate at Sonatype.
DJ: There are a lot of missing pieces out there and I think it's because nobody really knows where to go with it. If you do a search for DevSecOps reference architectures, you're going to see that infinity logo with a bunch of locks around it which doesn't really tell you much. I’ve created this one, but the community does need to share. I think it's because people don't really know which community they're part of; are they part of Secure DevOps, SecDevOps, OpsSecDev? I think there's confusion. So you might see some security reference architectures, but I don't know if they're really taking into consideration flow across the whole technology value stream.