devopsy.kinsta.cloud

Tag: application security

  • GitGuardian Survey Surfaces Secrets Management Challenges

    GitGuardian Survey Surfaces Secrets Management Challenges

    A survey of 507 IT decision-makers in the U.S. and the United Kingdom published today found 75% of respondents said a secret leaked from at least one application, with 60% noting that the leak caused issues for either the company, employees or both.

    Conducted by Sapio Research on behalf of GitGuardian, a provider of a platform for securing application secrets, the survey found less than half of respondents (48%) are confident in their ability to protect application secrets to a great extent.

    The top source of risks when it comes to secrets management are source code and repositories (58%), followed by hard-coded secrets (47%). Just under a third (30%) of respondents to the GitGuardian survey admitted they share passwords and secrets when building applications as clear text within a messaging application.

    Just over a quarter (27%) still relied on manual code reviews to prevent secrets leaks, the GitGuardian survey found.

    On the plus side, 94% of the respondents said they were considering improving their secrets management practices in the coming 12-18 months, even though 93% said either “all” or “some” of their repositories were continuously scanned for hard-coded secrets.

    Thomas Segura, a cybersecurity expert for GitGuardian, said as the number of applications developed continues to increase, secrets sprawl has become a bigger challenge for application security. The way secrets are managed during application development has become a bigger issue in the wake of a series of software supply chain breaches that led to malware being injected into applications.

    The concern is cybercriminals that compromise software development environments will be able to retrieve secrets that they can later use to compromise an application after it has been deployed in a production environment. Cybercriminals are also now routinely scanning for secrets that may have been stored in text after an application has been deployed.

    The challenge is that secrets have not been historically managed effectively, so many organizations are now looking to implement more rigorous processes. Another challenge is that, in many cases, it’s not apparent whether those processes will be implemented by a DevOps team familiar with how an application is constructed or an application security team with more cybersecurity expertise, noted Segura.

    Regardless of the approach to remediating these issues, there is always going to be an issue because the humans who build applications are always going to make mistakes. The goal is to minimize the number of secrets that might be leaked by implementing DevSecOps practices that automate the review process, said Segura.

    In theory, at least, advances in artificial intelligence (AI) should make it easier to automate more of the secrets review process. In the meantime, however, organizations need to review their existing processes in advance of pending legislation that looks to hold organizations more accountable for application security if it is determined that the organization did not take reasonable precautions.

    It may be a while before such legislation becomes law, but one way or another, it’s clear that DevOps teams are soon going to be asked tougher questions about how secrets were managed every time an application security breach occurs.

  • Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode has added a module to its platform for mapping metadata and events using graph technology that makes it simpler for application development and cybersecurity to consolidate alerts generated by their DevSevOps tools.

    Lotem Guy, vice president of product for Cycode, said the Cycode Application Security Orchestration and Correlation (ASOC) module will automatically discover all the tools that make up a DevSecOps workflow without requiring any integration effort.

    That capability makes it simpler to aggregate results in a way that enables development teams and cybersecurity professionals to identify the most critical issues that need to be addressed before applications are deployed in production environments, he added.

    In effect, Cycode is now providing a method for bridging the historic divide between cybersecurity professionals and application development teams. More cybersecurity professionals are embedded within DevOps teams, but in the absence of a platform for aggregating alerts, they often encounter communications issues. ASOC provides an agentless approach to aggregating the data that DevSecOps teams need to prioritize remediation efforts, said Guy.

    While a lot of progress has been made in terms of adopting DevSecOps best practices, many organizations still struggle with securing their software supply chains. Most of the members of a DevOps team have limited cybersecurity expertise, so they need the help of a cybersecurity professional to determine what specific actions are required to remediate a vulnerability. Cybersecurity professionals, conversely, don’t have a lot of application development expertise and generally would prefer not to be overwhelmed by multiple DevOps tools generating alerts about the same potential application security issue.

    As the number of regulations specifically focused on application security steadily increase, it’s now just a question of time before every organization that builds software will need to embrace DevSecOps. The challenge is that while everyone involved generally agrees software should be more secure before it’s deployed, the security tools made available to DevOps teams vary widely. In fact, it’s not uncommon for DevOps teams to find themselves spending significant amounts of time sorting through multiple conflicting alerts.

    Nor is every alert that gets generated relevant—in some cases, a specific module that generated an alert might not find its way into the final application. In addition, many of the alerts generated also tend to lack context about severity. Application developers can’t devote all their time to fixing bugs, so choices will need to be made based on the actual risk to the application.

    Cycode is betting that, as DevSecOps continues to evolve, organizations will look for tools and platforms that make it simpler to make sense of the current level of application security chaos that tends to pervade IT organizations. In the meantime, cybersecurity professionals and application developers will need to learn to trust one another. Developers have too often viewed cybersecurity as an obstacle to deployment while cybersecurity teams have historically considered developers to be one of the primary causes of the breaches they are expected to clean up. The first step toward achieving that goal is, of course, to realize that neither is really the enemy of the other.

  • How Application Developer Turnover is Shaping Security

    How Application Developer Turnover is Shaping Security

    Observing the developer job market for the past two years reveals a surprising truth that has a profound impact on technology organizations. In the “new normal” of hybrid work, life moves fast and there’s no sign of slowing down. Since 2021, we’ve witnessed all-time record demand for software engineering developers. The emergence of privately held large and medium technology startups, fueled by a fear of missing out (FOMO) driven venture capital market, created vast growth opportunities for software engineer developers in particular. From developing and deploying new applications to scaling your business through multi-cloud environments, cloud and cloud-native companies are everywhere. Not only are cloud and cloud-native companies receiving enormous funding rounds, but worldwide spending on public cloud services is forecasted to grow 20.7% to a total of $591.8 billion in 2023.

    This dramatic cloud growth is primarily driven by the warp speed developers are operating. Thanks to developers, every company is now a digital company and every industry is reaping the benefits of a cloud presence. A retail organization can now build and deploy an application for the holiday shopping season within hours, and workforces can access applications from their kitchen, local coffee shop, or halfway across the world.

    However, as with any new, widely adopted technology, cybercriminals look to target and exploit organizations in their early cloud days as they begin to grasp and understand the technology.

    It was reported earlier this year that the recent exposure of roughly a terabyte of Pentagon emails was likely due to a cloud configuration error. Cloud attacks are on the rise, and there is a major disconnect about who is responsible for keeping the organization safe. Developers who are told to build with speed don’t want their applications slowed down or user experience to be altered by security protocols. Still, accelerating application velocity has security teams caught between remaining responsive to application teams and securing an increasingly complex cloud environment. A major problem is bubbling up, and if security and developers teams cannot come together, the result can leave organizations vulnerable.

    Developers and Turnover

    In a recent survey, 75% of respondents reported a higher-than-usual turnover rate in DevOps. Similar to the well-documented cybersecurity talent shortage, multiple workplace stressors appear to be taking a toll on developers. The same survey reported that 38% of enterprises deploy code to production or release to end users every day, with 17% deploying multiple times a day. To put this into perspective, just two decades ago, developers were shipping limited updates one to two times a year.

    Given the pressure to deliver new code every day, combined with security teams’ pressure to ensure that code is secure, it’s no surprise that we’re witnessing higher-than-normal developer attrition. Instead of pointing fingers at developers for unsecure code, security teams need to create tools and training that do not impede their number one priority: Shipping new code. We’re in a developer-friendly job market and organizations cannot afford to lose top talent because they are overburdening them with security tasks. Developers will find greener pastures.

    Shifting Left

    By now, everyone in the industry has heard of shifting security left—the practice of moving security to the earliest possible point in the development process to ensure code is secure and limit timely and costly remediation. In practice, this means bringing security to where the developers operate so vulnerabilities and misconfigurations are caught early when they are easy to fix.

    This approach has brought about a deeper level of engagement between application developers and security teams, especially in the design phase. However, while developers might now be embracing tools and processes that help them code secure applications, there’s still a limit to how much shift left responsibility they can and want to handle.

    Path Forward

    Shifting security left is certainly a recommended starting point, but simply equipping developers with DevSecOps tools isn’t a winning approach. Developers must be trained and have the desire to effectively use the tools. Like the old saying, give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime. The same holds when shifting security left.

    To ensure developers and security teams understand their security responsibilities within the organization, consider implementing the following:

    1. Define a clear shift left strategy with developers and security teams
    2. Provision the necessary security tools that effectively protect the organization but don’t create roadblocks for developers. Additionally, more tools don’t necessarily mean more security, so be strategic.
    3. Train developers to be more mindful of cybersecurity issues. Most developers haven’t had formal cybersecurity training, so it’s up to organizations to make sure that particular skills gap is closed

    DevSecOps is as much about changing culture and approaches as it is about acquiring new tools. Developers will, unfortunately, come and go, but it should never be because security teams are overburdening them.

  • Cisco AppDynamics Survey Surfaces DevSecOps Challenges

    Cisco AppDynamics Survey Surfaces DevSecOps Challenges

    A survey of 1,150 large enterprise IT professionals from the AppDynamics unit of Cisco suggested application security progress is being made slowly and steadily as organizations continue to embrace DevSecOps best practices.

    The survey finds that while more than three-quarters of respondents (76%) believe that DevSecOps is essential for organizations to effectively protect against a multi-staged security attack on the full application stack only 43% reported their organization has already started to implement DevSecOps workflows while another 46% said they are currently considering making the shift.

    More than three-quarters of respondents (78%) also said a lack of a shared vision between application development and security teams presents a challenge to application security over the next 12 months. More than half (55%) said they currently considered security to be more of an inhibitor of innovation than an enabler. Nevertheless, 81% admitted a lack of application security skills and resources is now an issue for their organization, with 79% acknowledging that securing the full application stack is now a priority for their organization.

    A full 92% admitted that the rush to rapidly innovate and respond to the changing needs of customers and users during the COVID-19 pandemic has come at the expense of robust application security. Well over half of respondents (58%) also noted their organization often ended up in ‘security limbo’ because they didn’t know what security issues to focus on and prioritize. A total of 88% acknowledged their organization could be doing more to secure the full stack of modern applications across the entire application life cycle.

    Not surprisingly, 93% said it’s important to be able to contextualize security so that they can correlate risk in relation to, for example, application performance, end user experience and business metrics. However, more than two-thirds (68%) reported that their current security solutions work well in silos but not together. A total of 85% stated that cultural changes to support the shift to a DevSecOps approach are important to improve application security.

    AppDynamics Executive CTO Gregg Ostrowski said it is apparent organizations are still wrestling with not just application security technologies but also people and process issues. The most critical issue is to knock down the silos that exist in organizations that often result in one team demonizing another, he added.

    Overall, application security is becoming more challenging as the attack surface expands. A full 89% of technologists reported that their organization experienced an expansion in its attack surfaces over the last two years, with almost half (46%) noting that this expansion is already increasing cybersecurity challenges. One of the primary drives of that expansion as been the rise of the internet-of-things (IoT) applications (59%), rapid adoption of cloud computing platforms (56%) and digital business transformation initiatives (51%).

    On the plus side, more than three-quarters of respondents (76%) said they believe artificial intelligence (AI) will play an increasingly important role in addressing application security challenges. The issue, of course, is how soon those advances might be made at a time when attacks against software supply chains are clearly on the rise.

  • Okta Makes No-Code Integration Tool for Identity Platform Available

    Okta Makes No-Code Integration Tool for Identity Platform Available

    Okta today made generally available an Actions Integration capability that makes it possible to integrate third-party tools without having to write any code.

    Shiven Ramji, chief product officer for Okta, said this no-code integration capability for the Okta Customer Identity Cloud extends a simpler approach for managing secrets that is invoked via an application programming interface (API).

    At a time when more responsibility for application security is being shifted left toward developers, the Okta Customer Identity Cloud is gaining traction as an alternative for managing secrets more securely, noted Ramji. Rather than developers attempting to manually verify the identity of end users, it becomes easier to manage identity flows within the context of a larger application development workflow using a cloud service, he added.

    In addition to giving developers access to Actions Integration, Okta is also making third-party integrations developed by partners available via the Auth0 Marketplace. The goal is to encourage providers of application development tools to build integrations that development teams can simply download when needed, said Ramji.

    It’s not clear how much influence developers are exerting over how identity is managed as more organizations embrace DevSecOps best practices for building and deploying applications. Regardless of approach, the overall state of application security should continue to improve as developers embrace new methods of managing identity within their applications. One of the issues that frequently creates a security breach is when developers forget to remove secrets created during the application development process before an application is deployed in a production environment. Cybercriminals today routinely scan for secrets that have been inadvertently stored as text within an application.

    Lees clear is the degree to which developers may opt to update existing applications to take advantage of identity management services that can be invoked via an API or whether they will opt to switch to a cloud service for only new applications.

    One way or another, organizations of all sizes will need to find a way to make it easier for developers to manage identities across multiple applications. There is often a tendency to ascribe responsibility for managing identities to development teams without always providing access to a set of tools to manage the process. In about half of the instances in which organizations adopt Okta Customer Identity Cloud, the decision is made by developers, said Ramji. Many of those developers discover the Okta service when they are building a proof-of-concept for their application, he added.

    The other half of the time the decision is made by more senior leaders on behalf of an entire development team, said Ramji. In some of those cases, organizations are even going to far as to create a team of specialists for managing identities across a portfolio of applications, he noted.

    The core issue, as always, is determining how much time and effort developers will want to spend on identity management versus writing business logic code. All things considered, most developers are going to find it a lot more convenient to invoke an API to access a cloud service versus setting up and maintaining a vault full of application secrets on their own.

  • AppSec in the Cloud: What DevOps Teams Should Know

    AppSec in the Cloud: What DevOps Teams Should Know

    Cloud application security refers to the measures and controls that are put in place to protect cloud-based applications and data from cyberthreats, unauthorized access and data breaches. These measures can include technical controls such as encryption, access controls and secure networks, as well as operational controls like policies and procedures for managing and securing data in the cloud.

    Cloud application security is important because it helps to ensure the confidentiality, integrity and availability of data and applications in the cloud. It is especially critical for organizations that store sensitive or regulated data in the cloud, as a security breach could have serious consequences for the organization and its customers.

    There are many different approaches to cloud application security, including the use of security protocols, identity and access management (IAM) systems and security information and event management (SIEM) tools. Some organizations may also choose to use cloud security platforms, which provide a range of security services and tools that can be used to protect cloud-based applications and data.

    How DevOps Secures the Cloud

    DevOps is a software development approach that aims to optimize the collaboration and communication between development and operations teams to deliver software more quickly and efficiently. It involves using automation, continuous integration and delivery and other tools and practices to streamline the software development process.

    Cloud security operations, or CloudSecOps, refers to the practices, processes and tools used to secure and manage cloud-based applications, systems and data. CloudSecOps is a key aspect of DevOps, as it helps to ensure that cloud-based applications and systems are secure and compliant, while also allowing for rapid deployment, scaling and management of applications in the cloud.

    There are several key ways that CloudSecOps can be implemented in the cloud as part of a DevOps approach:

    • Automated security testing: CloudSecOps can be implemented using automated security testing tools, which can be integrated into the CI/CD pipeline to continuously test and validate the security of code changes.
    • Identity and access management: CloudSecOps involves using identity and access management (IAM) systems to control and monitor access to cloud-based resources. These systems can be integrated into the DevOps process to ensure that access to cloud-based systems is properly managed and secured.
    • Security as Code: CloudSecOps can be implemented using security-as-code practices, which involve writing security policies and controls in code and integrating them into the CI/CD pipeline. This allows organizations to automatically enforce security controls as part of the software development process.

    4 Cloud Application Security Best Practices

    Understanding and Monitoring Dependencies in Cloud Applications

    Application dependency mapping is a technique that can be used to visualize and understand the dependencies between different components of a cloud application. This can help organizations identify and manage the risks associated with dependencies and ensure that all application components are up-to-date and secure.

    There are several key benefits to using application dependency mapping as a cloud application security best practice:

    • Improved visibility: Application dependency mapping provides a clear and comprehensive view of the dependencies between different components of the application, which can help organizations to better understand the risks associated with these dependencies.
    • Improved risk management: By understanding the dependencies between different application components, organizations can identify and prioritize the most critical dependencies and take steps to mitigate any associated risks.
    • Improved security: By regularly monitoring dependencies for updates and vulnerabilities, organizations can ensure that all application components are secure and up-to-date.
    • Improved compliance: By understanding and managing the dependencies between different application components, organizations can ensure that they meet compliance requirements for storing and processing data in the cloud.

    Cloud Database Security

    Cloud database security is a critical aspect of cloud application security, as it involves the measures and controls that are put in place to protect data stored in the cloud from cyberthreats, unauthorized access and data breaches. 

    Ensuring the security of cloud-based databases is important because these systems often store sensitive or regulated data. A security breach could have serious consequences for the organization and its customers.

    There are several key best practices for ensuring the security of cloud-based databases:

    • Encryption: Encrypting data at rest and in transit can help to protect against unauthorized access to data stored in the cloud.
    • Access controls: Implementing fine-grained access controls can help to ensure that only authorized users have access to data stored in the cloud.
    • Security monitoring: Monitoring for security events and anomalies can help to identify and respond to potential threats to data stored in the cloud.
    • Compliance: Ensuring that cloud-based databases meet compliance requirements for storing and processing data is an important best practice to protect against data breaches and ensure regulatory compliance.

    Apply Cloud Governance Policies

    Cloud governance refers to the practices, processes, and controls used to manage and govern the use of cloud-based resources and services. Some of the key ways that organizations can apply cloud governance policies to improve the security of their cloud-based systems include:

    • Establishing policies for access and use: Organizations can establish policies that define who has access to cloud-based resources and how they can be used. This can help to ensure that access to sensitive data and systems is properly controlled and monitored.
    • Implementing security controls: Organizations can implement security controls such as encryption, access controls and secure networks to protect data and systems in the cloud.
    • Ensuring compliance: Organizations can establish policies and procedures to meet compliance requirements for storing and processing data in the cloud.
    • Monitoring and auditing: Organizations can establish policies for monitoring and auditing the use of cloud-based resources to ensure that they are being used in accordance with established policies and procedures.

    Identify, Categorize and Protect Sensitive Data Stored in the Cloud

    Sensitive data refers to information that is highly confidential or regulated and that requires special protection to ensure its confidentiality, integrity, and availability. There are several key steps that organizations can take to identify, categorize and protect sensitive data stored in the cloud:

    1. Identify sensitive data: The first step is to identify the sensitive data stored in the cloud. This may include personal data, financial data, intellectual property and other types of sensitive information.
    2. Categorize sensitive data: Once the sensitive data has been identified, it is important to categorize it based on its level of sensitivity and the potential risks associated with it. This can help organizations to prioritize the protection of different types of sensitive data.
    3. Protect sensitive data: There are several different measures that organizations can take to protect sensitive data stored in the cloud, including encryption, access controls and secure networks. It is also important to implement policies and procedures to ensure that sensitive data is handled and processed securely.

    Conclusion

    In conclusion, application security in the cloud is a critical concern for DevOps teams, as it involves the measures and controls that are put in place to protect cloud-based applications and data from cyber threats, unauthorized access, and data breaches. 

    To ensure the security of their cloud-based systems, DevOps teams should implement a range of best practices, including understanding and monitoring dependencies, implementing security controls, managing identities and access, and ensuring compliance. By following these best practices, DevOps teams can help to ensure the security and integrity of their cloud-based systems and protect against potential threats.

  • Rezilion Updates Open Source MI-X Tool to Better Secure App Development

    Rezilion Updates Open Source MI-X Tool to Better Secure App Development

    Rezilion has updated its open source MI-X vulnerability discovery tool to include mitigation and remediation recommendations.

    In addition, the tool can now produce machine-readable output in either a JSON or CSV format.

    Finally, the company added Windows support for Heartbleed and SpookySSL vulnerabilities in Windows environments.

    MI-X makes it possible to use a command line interface (CLI) tool to identify and establish the exploitability of more than 20 well-known common vulnerabilities and exposures (CVEs).

    Yotam Perkal, director of vulnerability research for Rezilion, said Rezilion created the tool as part of its efforts to create a platform that enables organizations to better secure their software supply chains. The primary purpose of the platform is to prevent vulnerabilities from being introduced into applications in the first place by providing developers with the context required to understand the potential severity of a vulnerability, he added.

    There’s no doubt that developers need tools that enable them to easily identify vulnerabilities while writing code. However, shifting responsibility for vulnerabilities entirely left toward developers is not a panacea for application security. DevOps teams need to embrace DevSecOps best practices to ensure that the build created by multiple developers is secure and that the runtime environment where applications run is also free of malware.

    The challenge is that achieving that goal needs to go beyond adding additional tools to a DevOps workflow. The biggest challenge is narrowing the historic cultural divide between developers and cybersecurity teams tasked with discovering vulnerabilities. Most cybersecurity professionals don’t understand how applications are developed, so every instance of vulnerability found in an application looks the same to them—regardless of whether the actual code is externally accessible.

    DevOps teams, meanwhile, are trying to strike a delicate balance between patching innumerable vulnerabilities and building and deploying additional applications. More than anything, those teams need to be able to prioritize their patching efforts based on the actual versus theoretical severity of a vulnerability, noted Perkal.

    It may never be possible to address all the application security debt application environments have accrued over the years. However, as apps are built and application security issues are addressed more proactively, the state of cybersecurity should improve. The issue, of course, is that cybercriminals are now targeting software supply chains; inserting malware into a DevOps workflow creates a potential opportunity to compromise any number of downstream applications. Organizations are now racing against time to secure their software supply chains.

    The good news is that no developer intentionally sets out to build an insecure application. It’s just that far too many of them have been conditioned to think of security as an obstacle they need to overcome rather than address. However, the more tools they are provided to remediate as many vulnerabilities as possible, the better off everyone concerned will be.

  • Survey Surfaces Raft of DevSecOps Cultural and Technical Challenges

    Survey Surfaces Raft of DevSecOps Cultural and Technical Challenges

    A global survey of 606 IT, security, application development and DevOps decision-makers found that the biggest barrier to adoption of DevSecOps best practices is cultural rather than technical. However, the survey, which polled organizations with more than 500 employees and was conducted by Progress, also found only 16% of respondents planned to prioritize addressing those cultural issues in the next 12 to 18 months.

    A full 71% of respondents cited culture as the biggest barrier to DevSecOps progress, with only 30% expressing confidence in the current level of collaboration between security and application development teams currently being achieved. In contrast, 46% of respondents were not particularly confident while nearly a quarter (24%) were not at all confident.

    Nevertheless, well over half of respondents (57%) said security threats are the number-one technology factor driving the evolution of DevSecOps, even though just over half (51%) admitted they were only somewhat familiar with how security fit into a DevSecOps workflow.

    Overall, 86%of respondents said they are experiencing security challenges that include prioritizing externally facing applications over internal applications (47%), securing different types of workloads that were using different development and delivery methodologies (46%), meeting delivery deadlines (45%) and meeting audit requirements specified by the security team (39%). Just over three quarters (76%) recognized they could be more strategic in managing DevSecOps.

    The top three initiatives needed to support a shift to a more strategic DevSecOps approach identified are more investment in continuous learning for developers and engineers (61%), upskilling of developers and engineers to move into site reliability engineering (SRE) roles (60%) and improved communication between developers, security and operations (60%).

    Survey respondents also identified a need to define a clear set of policies and procedures (66%), define the role and responsibilities of staff across teams (62%), create a continuous feedback loop (49%) and automate recurring security tasks (41%).
    Despite that level of awareness, however, only 40% said they believed implementing security training and upskilling efforts across multiple stakeholders was very important when implementing DevSecOps.

    Prashanth Nanjundappa, vice president of product management for Progress, said given all the cultural and technical challenges organizations face, it’s apparent that both a top-down and bottom-up approach to implementing DevSecOps best practices is required. Attempting to shift responsibility left toward application development teams is not going to suffice on its own, he noted.

    The survey also suggested that many organizations are trying to address application security issues as they modernize their application portfolio. A total of 59% said they struggled to attain buy-in/funding for refactoring efforts that didn’t provide new user capabilities. However, only 39% said they had adopted a comprehensive modernization approach based on cloud-native architecture principles, while another 22% felt they lacked one entirely. Just under a quarter (24%) said their approach to modernization is to largely rip-and-replace applications.

    The top business factor driving the adoption of DevSecOps was a focus on business agility enabled by fast and frequent delivery of application capabilities (59%). Just under half (45%) said it had taken six to 12 months to achieve a return on DevSecOps investments, while 31% said it had taken longer than a year. However, only half (50%) of respondents were familiar and interested in both infrastructure and policy-as-code.

    There is no doubt that the DevSecOps journey ahead will be long and arduous. However, there are also a wide range of small process changes that could have a massive impact in terms of improving application security in the short term. The challenge is to quickly identify those opportunities while at the same time employing a more systematic approach that ultimately makes it a lot simpler to implement a set of DevSecOps best practices consistently.

  • Shift That [bleep] Left

    Shift That [bleep] Left

    Seriously. The more you can shift things like security and test to the left, the more responsive the DevOps process will be. Some things are better shifted right … But only while solving the problem with shifted-left work. A good example is blocking zero-day attacks proactively while the development process fixes the code to stop the attacks permanently.

    One thing we in IT are terrible about is following up on that “fix it” part—because we are very busy. Once a problem is blocked, we tend to fight other fires because we have too many things going on. We have absolutely got to get better about that. But I don’t want to get sidetracked. Today’s topic is about fixing bugs/vulnerabilities as they are created.

    One of the issues with the way we used to handle test and security was that by the time we had “This is an issue we need to fix,” feedback, the developer was off doing other things. But with the increasing inclusion of security and testing in the DevOps process, we now have the ability to provide feedback far more quickly.

    My favorite innovation in the DevOps space is not some wild new bug/vulnerability detection feature, nor is it rampant use of AI (though some uses of AI do come close to being my favorite). It is the humble IDE plugin.  As a developer, writing buggy or insecure code is never the goal, but it happens every day. IDE plug-ins, hooked into test and security software, allow developers to get a heads-up that there might be an issue while writing the code. This not only addresses the problem while it is fresh in the developer’s mind, it also allows developers the opportunity to improve their craft simply by understanding which issues they create often and learning how to avoid them.

    We have all written bad code. I once actually over-wrote databases for a bank; it was a great humbling and learning experience for a young hotshot who needed to be reminded he was not perfect when coding. Others no doubt have similar, if less catastrophic, stories to tell. The ability to get warned about issues—but quality and security—while writing the code cannot be overestimated. Some developers will hate it because it is more intrusive than the old school “Okay, all the code is written, you can test now,” process, but it is powerful precisely because it is more intrusive and proactive.

    The challenge for those in the testing and development security spaces will be to keep false positives at a minimum. I’d say zero, but I’d rather get the occasional “Oh, that. Yeah, not an issue in this case,” than go through having it tell me things throughout development and still end up with buggy/insecure code.

    You all are still rocking it. The amount of software in use every day across the world is staggering, and you’re cranking it out and keeping it maintained—whether you’re working on internal applications or commercial packages. You’re making it work. Take a look at QA and security IDE plug-ins, make an honest assessment of whether they could make your work more secure and/or higher quality. I think they can for nearly all of us. And they can save time by doing it earlier in the development process. And maybe you’ll get recognized for rocking it. Okay, probably not, but it is possible.

  • 2023 Application Security Budgets on the Rise

    2023 Application Security Budgets on the Rise

    A survey of 500 DevSecOps professionals in the U.S. found nearly three-quarters (73%) of organizations plan to increase investment in application security in 2023.

    The survey, conducted by Wakefield Research on behalf of Invicti, a provider of dynamic application security testing (DAST) tools, also found 97% of DevSecOps teams said they ignored a real vulnerability at least once a month because they assumed it was a false positive.

    Invicti CTO and head of security research Frank Catucci said that while it is apparent organizations are under pressure to improve the security of their software supply chains, the tools and processes used to discover vulnerabilities need to be revisited at a time when the security technical debt accrued in production environments is already massive.

    Many DevOps teams have routinely shipped code with known vulnerabilities for years, noted Catucci. They are not only under pressure to improve the security of new applications but also remediate applications with known vulnerabilities already running in production environments, he added.

    Cybersecurity teams have, of course, been identifying those vulnerabilities for years. The challenge is that the long list of vulnerabilities cybersecurity teams provide to DevSecOps teams tends to lack any context. As such, it becomes impossible for developers to prioritize their remediation efforts based on the actual severity of the vulnerabilities found. DAST tools help address that issue because they provide insights into vulnerabilities in applications already running in a production environment.

    Application security, of course, has historically been problematic because many developers assume cybersecurity teams are securing the environments where applications are deployed. Most cybersecurity teams, however, allocate their budgets to tools and platforms they control and manage. Most of those tools and platforms are focused on security operations tasks that tend to have more to do with securing infrastructure rather than applications. The assumption is application development teams are responsible for securing the software that runs on those platforms. That disconnect is now finally being addressed as responsibility for application security shifts left to become an integral part of DevOps workflows.

    The Invicti survey suggested that application security budget allocations are now catching up with that transition. In fact, the Invicti survey found that 100% of DevSecOps professionals are tracking the return on investment (ROI) on the application security tools and platforms they employ. Of course, measuring the effectiveness of any cybersecurity tool or platform has always been a challenge. It’s never quite clear whether a breach didn’t occur because a tool or platform was present or if it didn’t happen because of sheer luck and happenstance.

    Regardless of the ROI achieved, however, it’s clear that cybercriminals are increasingly targeting software supply chains. The recent executive order issued by the Biden administration requiring federal agencies to review the security of their software supply chains got the attention of traditional enterprise IT organizations, as well. As such, the overall state of application security should steadily improve in the months and years ahead, as more funding is allocated to prevent vulnerabilities from finding their way into production environments in the first place.