devopsy.kinsta.cloud

Tag: appsec

  • Bridging the AppSec and DevOps Disconnect

    Bridging the AppSec and DevOps Disconnect

    Research estimates that cybercrime is going to cost the world $10.5 trillion annually by 2025, so it is no surprise that cybersecurity has become a top priority for business leaders. 

    Today, security teams are striving to harden their systems against cyberattacks and improve their resilience through more employee security training, incident response programs and the implementation of technology to monitor and detect threats. 

    Many organizations are also adopting a shift left security strategy, where security is being addressed earlier in the application development life cycle. These organizations are realizing that finding security issues in their software after it’s released is much riskier and more costly. After all, the longer a bug is in the wild, the longer an attacker has to find and exploit it. By implementing a shift left security strategy, the window of opportunity for an attacker decreases or can be completely removed if a security issue is addressed in the development stages, while also offering organizations significant security benefits and cost savings. 

    Shifting left is a security testing strategy where DevOps and security teams work in tandem to identify and address vulnerabilities during early development stages. This process significantly improves security as it means vulnerabilities are identified and mitigated before they are introduced to the enterprise environment.

    However, one of the biggest challenges organizations face when adopting a shift left security strategy (DevSecOps) is encouraging security teams and DevOps teams to work together.

    Encouraging AppSec and DevOps Collaboration

    Until recently, DevOps teams and AppSec teams were completely siloed. DevOps teams worked on accelerating the speed at which applications are released into the enterprise; application security teams only got involved in the later stages. However, this process has caused security concerns, particularly as more organizations move to agile development. 

    When security teams eventually got their hands on new applications and updates, security flaws were inevitably found that caused delays and friction with DevOps teams. 

    However, as organizations begin to embrace DevSecOps and shift left strategies, these two previously siloed teams are being forced to work together more closely. So, how can the friction be reduced and the disconnect bridged?

    Culturally, some ingrained attitudes and behaviors challenge the success of any DevSecOps efforts. Security teams have seen DevOps processes accelerate the speed at which software is delivered, but without security considerations, while DevOps teams experienced security slowing down processes and giving inconsistent results and feedback on security issues. Each party has their own manager to please; their own set of metrics that they’re measured against and a priority list as long as their arms already. Both teams follow different processes and, crucially, use different tools. DevOps can’t get around the security tool complexity and lack of integration with their existing toolset and security teams have no control over the CI pipeline to best implement security assurance.

    One of the best ways to overcome this friction is through better technology, process and culture that enables collaboration between teams. First, DevOps teams do care about security, but it might be lower on their priority list. Security teams must understand that DevOps teams care about code, quality and efficiency. They are not security experts and just because an organization is shifting left doesn’t mean they need to become one. Instead, organizations should implement tools for DevOps where security checks can be easily embedded.

    So, what can organizations do to improve the collaboration between AppSec and DevOps teams to achieve DevSecOps?

    DevSecOps is a culture and it requires a shift in thinking. Security teams and DevOps teams need to understand each other’s priorities and understand that by working together they are improving the overall security of the organization and decreasing the risk of cyberattacks. Does the DevOps team understand the potential risks a vulnerability could have on the organization overall? If not, security teams need to educate them.  

    Security automation tools offer great support when organizations are moving to DevSecOps, as they allow bugs and vulnerabilities to be flagged automatically as applications are being developed. This will allow them to be addressed before services go live; however, because they generate frequent alerts, this could add to DevOps’ already busy workloads. By deploying tools which can be synced with CI/CD pipelines and provide custom advisories so DevOps teams can address bugs themselves without having to ask AppSec teams, this can significantly speed up the process, reduce friction and ease workloads.

  • Mastering the Shared Responsibility Model

    Mastering the Shared Responsibility Model

    It’s no secret that cloud-native application development is growing exponentially, with Agile development, IaaS and PaaS from providers like Amazon, Microsoft and Google, enabling innovation at a pace that is challenging for security to keep up with. 

    A global pandemic and the resulting remote work mandates have only accelerated this movement. And with this change in distributed work and agile application development comes greater security considerations—and a higher degree of risk to the business. Security in the cloud is a shared responsibility, but too many organizations find it difficult to fully understand their role in the security of their applications. There are many elements of securing cloud-native applications that cannot be delegated. They require careful attention as part of a risk-based application security program that extends from design to development throughout their application development life cycle.

    With the appropriate visibility, risk-based thinking and automation, cloud-native applications have the ability to be more secure than ever, while enabling faster development and delivery at the same time. But to get to this point, organizations need to understand their responsibilities. 

    Cloud infrastructure security and compliance are necessities for ensuring how applications and data are deployed and operated in the cloud. But what about what is in those applications? Applications are made up of lines of application/infrastructure code and open source libraries built by developers, DevOps, product managers, security champions and other roles. 

    How do we know the components that make up the application are effectively secured? It is too late and not enough to solely rely on a secure cloud posture. Reducing risk early in the development lifecycle will dramatically reduce costs and business risk. Some sources have assessed the cost impact of fixing a risk in early production to be four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase.

    Modern applications are delivered through sophisticated “plumbing” of secure cloud infrastructure to our device interfaces. Just as we require clean and safe water to transit the physical plumbing into our homes, we need our applications to remain secure and high-quality as they transit cloud services.

    The IaaS/PaaS Shared Responsibility Model

    The best way to think about security in this cloud-native world is by using a shared responsibility model, with IaaS customers only responsible for certain elements of the security of an application that lies on top of the infrastructure. 

    In the traditional shared responsibility model, IaaS vendors are responsible for the configuration, management and security of infrastructure elements such as networking, databases and compute engines, in addition to physical security, redundancy and more. But each of their customers is responsible for the security and privacy of everything on top of that, from design to code to deployment.

    The Traditional IaaS/PaaS Shared Responsibility Model

    The Customer Side of the Shared Responsibility Model

    What’s missing from this model are software design, code risk and CI/CD security and integrity—and these areas are the most difficult, time-consuming and require a well-thought-out and comprehensive application security program.

    With new approaches to application security, organizations can better understand the risk of their cloud-native applications and automate a significant amount of risk remediation activities at the design or coding phases before deploying to the cloud. This requires taking a broad but contextual view of AppSec across the entire SDLC—and the modern nature of attacks requires a complete view of the SDLC to understand where the most impactful business risk lies.

    Organizations must evaluate the full picture of their risk—from design to code to cloud:

    1. Visibility—Understanding your risk starts with visibility into your security and compliance risks with a real-time inventory of assets, application and infrastructure code behavior, developer knowledge, third-party security alerts, sensitive data and business impact.
    2. Secure by Design—You need to make sure that security is addressed at the design stage—before any code has been written or committed.
    3. Change Management—Organizations need to focus on the risks that matter early in the development process and based on business impact. Material changes to the applications and infrastructure should be carefully evaluated while other changes can be approved more quickly or ignored, thereby accelerating product delivery.
    4. CI/CD Security and Integrity—As an ever-running, highly-trusted and sensitive process, CI/CD is often overlooked. Many attacks in the recent past exploited this Achilles’ heel of the development cycle by embedding attackers’ code within native code commits or other automatic CI/CD processes. Organizations should ensure CI/CD operations are secure with integrity and security checks in place.
    5. App & Infra Risks Together—To properly secure your applications, you must correlate the risks of your applications and infrastructure in one platform.
    6. Automation—Automation must also be employed to limit mistakes caused by human error, ensure consistency in enforcement of policies and increase the speed of the DevSecOps process. Organizations must carefully manage this process, because automation can also introduce a new category of issues, such as race conditions, untimely triggering, incomplete state validation for edge cases, etc.

    Infrastructure-as-Code (IaC)

    The human element of risk has changed with IaaS and PaaS due to the power that cloud administrators now have. Instead of purchasing, configuring and deploying servers over a period of months, an admin can spin up a Kubernetes cluster or an S3 storage bucket, load customer data and expose it to the Internet with relevant identity and access management (IAM) policies in record time via infrastructure-as-code (IaC) using GitOps instead of ClickOps.

    The rise of IaC has enabled us to view, evaluate and respond to infrastructure changes in the same way we would any application code change. Organizations must apply the same governance rules and automation to review changes in infrastructure before they reach production, along with real-time analysis of cloud misconfiguration. 

    The main challenge is context! All IaC tools in the market today are looking at security misconfiguration as a single dimension (for example, an S3 bucket missing encryption; a cloud database missing SSL for incoming connections, etc.) and this creates a lot of noisy alerts. The risks of cloud infrastructure and the applications that run on top of it are inherently connected—it is harder to connect the dots and understand the true risk of changes than it is to accept alerts at face value!

    When securing your applications in the cloud, don’t rely on traditional tools and processes. Today’s technologies enable new approaches that help you understand and remediate risk in entirely new ways and make cloud-native applications more secure than ever.

  • Data Theorem Adds Runtime Protection Enabled by Observability

    Data Theorem Adds Runtime Protection Enabled by Observability

    Data Theorem, Inc. this week added an Active Protection offering to its portfolio of application security services that makes it possible for DevOps teams to embed observability and runtime defenses in their applications via a software development kit (SDK).

    The Data Theorem cloud services are based on Trustkit, an open source framework the company created to make it easier to employ secure socket layer (SSL) to encrypt connections and Analyzer Engine, its runtime analytics engine.

    The company is now extending its services to make it possible to embed observability capabilities by collecting logs and traces. Those logs and traces are then used to enforce runtime security policies that protect applications from known attacks from malicious sources and other common attack vectors as defined by the Open Web Application Security Project (OWASP) Foundation. It also prevents violations of encryption levels, authentication types and authorization rules along with a variety of custom rule checks, including preventing broken object-level authorization (BOLA) attacks.

    Doug Dooley, Data Theorem COO, said Active Protection can be applied across any application stack, including microservices applications based on cloud-native frameworks. In contrast, existing approaches to securing application runtimes based on web application firewalls (WAFs), runtime application self-protection (RASPs) or endpoint detection and response (EDR) agents cannot be applied to cloud-native applications based on containers and serverless computing frameworks.

    Active Protection solves that issue because it is designed to be applied via the Data Theorem software development kit (SDK) or using application extensions made available via a serverless computing framework or as a container sidecar.

    Dooley noted that the Active Protection service is also designed to be fully integrated with DevSecOps workflows that are increasingly being driven via continuous integration/continuous delivery (CI/CD) platforms to enable continuous, automated security inspection and remediation. The company claims to have detected more than one billion application incidents and is currently used by more than 8,000 applications.

    Developers don’t generally set out to build and deploy insecure applications. The issue is most developers don’t have a lot of security expertise, so it’s easy for mistakes to be made. Organizations looking to embrace DevSecOps best practices need to find a way to achieve that goal in a way that developers can easily embrace. The more automated the checks for security issues become during the application development process, the more likely it is developers will make additional efforts to remediate vulnerabilities long before an application is ever deployed in a production environment. In effect, DevSecOps is easier to achieve when addressed from the bottom up rather than via an edict from above without any real implementation plan in place.

    It’s still early days as far as DevSecOps is concerned, but as best practices for DevOps continue to evolve, there may come a day when security is just another gate that needs to be passed within the context of a larger DevOps workflow. In the meantime, DevOps teams and cybersecurity teams should put aside their differences and work together as the number of attacks launched against applications increases.

  • Secure Coding Adventure Park Virtual Summit: Wilder, Faster and More Visionary Than Ever

    Secure Coding Adventure Park Virtual Summit: Wilder, Faster and More Visionary Than Ever

    DevSecOps helps secure code from the start of production, rather than patching and debugging it at a later stage. It brings development, operations and security teams together so they can release secure software faster. At Secure Coding Adventure Park Virtual Summit, taking place on September 29, industry-leading AppSec and DevSecOps practitioners, analysts and visionaries will come together to share their wildest rides on the security roller coaster and discuss everything you need to know about build secure code from the ground up.

    The agenda for Secure Coding Adventure Park Virtual Summit features a mix of topics, including AppSec, DevSecOps, open-source security, CI/CD and more.

    Security luminaries from AWS, Secure Code Warrior, GitLab, Sysdig, WhiteSource and many other well-known IT companies, will discuss:

    • How to prevent supply chain attacks from code through production
    • Why developers struggle with application security
    • The role of AppSec testing in securing your software supply chain
    • How to protect your open source projects and create a secure CI/CD pipeline
    • How remote work has influenced DevSecOps adoption
    • How to best approach modern software security by automating your CI pipeline for simplicity, visibility and control

    This year’s Secure Coding features outstanding industry leaders, such as:

    • Harry Mower, general manager, AWS DevOps Tools at Amazon Web Services
    • Maciej Mensfeld, senior product manager at WhiteSource
    • Marina Segal, director of product management at Sysdig
    • Stefania Chaplin, EMEA’s solution architect at Secure Code Warrior
    • Cindy Blake, senior product marketing manager and security evangelist at GitLab
    • Rhys Arkins, director of product management at WhiteSource
    • Eric Tice, director global open source technical consulting and COE at Wipro
    • Jayne Groll, co-founder and CEO at DevOps Institute
    • Eilam Milner, co-founder and CTO at Argon Security
    • Jonathan Leitschuh, security software engineer at Gradle Inc.
    • Ricardo Sueiras, technical evangelist at AWS
    • Sonya Moisset, principal security engineer at Photobox, Epic Women in Cyber/Tech founder, GirlCode ambassador
    • Scott Gerlach, co-founder and CSO at StackHawk
    • Dave Walker, principal specialist solution architect for security and compliance at AWS

    Our very own Jackie Whetzel sat down with Stefania Chaplin for a quick interview about her upcoming session at Secure Coding Adventure Park Virtual Summit, women in tech and her journey as a solutions architect. Check out a clip of the interview below as Stefania shares a sneak peek of what to expect from her upcoming session.

    To check out the full agenda and to register, visit the Secure Coding Adventure Park Virtual Summit website.

  • AppSec Marketing in the Age of DevSecOps

    AppSec Marketing in the Age of DevSecOps

    A while back, I had a conversation with a friend I went to school with (currently a senior member of the engineering team at a large retail chain) who was tasked with the job of identifying potential application security partners (he addressed vendors as partners, which I personally liked) to collaborate with on various areas as part of their product security initiative. The following piece emerged as an extension of my immediate thoughts when he shared his views of what could have made his experience of interacting with front-line sales and marketing folks better.

    In the context of DevSecOps, much has been said about the need for engineering to speak security, security to speak code, DevOps to speak security, etc. But as a technology service provider (TSP) riding the current wave of application security, it’s almost mandatory for the sales and marketing teams to also speak relevant tech!

    Application Security Is Not One-Size-Fits-All

    Application security, as a practice area, is dynamic. No two applications are the same, even if they belong in the same market domain, presumably operating on identical business use cases. Some (of the many) factors that cause this variance include technology stack of choice, the programming style of developers, the culture of the product engineering team, priority of the business, platforms used etc. This, consequently, results in a wide spectrum of unique customer needs.

    Take penetration testing as an example. This is a practice area that is, presumably, well-entrenched both as a need and as an offering in the application security market. However, in today’s age, even a singular requirement such as this could make or break an initial conversation. While for one prospect, the need could be to conduct the test from a compliance-only perspective, another’s need could stem from a proactive software security initiative. There are many others who have internal assessment teams and often look outside for a third-party view. Others who are further along the maturity curve could be looking to up their game through a hybrid approach of tool automation with a complementary method of manual assessments. I’m not even considering the added complexity involved in the nomenclature of such a service—is it called penetration testing, security testing, vulnerability testing, VAPT (which actually is a combination of two independent practices) etc.?

    Each of these unique needs emerges from buyer personas which emerge from varying degrees of informed decision making. TSP’s would need to retrofit their positioning accordingly. They often run the risk of underwhelming a mature buyer or overwhelming an early practitioner, especially in high variance offerings such as security tooling, security regression and threat modeling, for example. While some might argue that losing an overwhelmed prospect could be the result of their accurate customer segmentation, there are other reasons for this.

    Scoping questions, such as the ones below, can significantly help technology marketers strike the right chord with their prospects and elevate the experience of the initial interaction.

    • What is the motivation for the penetration test? Is it compliance regulation, internal validation, business drivers, their customers’ needs, etc.?
    • What are they specifically looking from a third-party partner? Is it external certification, a specialized approach, uncovering logic flaws, etc.?
    • What is the current appetite (measured in resource bandwidth, commerce) to take on your advanced offering? (Such as automation, regression etc.?)
    • How security aware are the developers? Can they take the findings to their logical conclusion through successful remediation?

    DevSecOps Is About the Journey, Not the Destination

    Ever since the surge of DevSecOps, marketers and practitioners have been vocal about the possibilities and advantages that smart automation brings with it. Think tanks, too, have statistically alluded to its benefits in terms of cost savings and bandwidth efficiency, among others. Though recent marketing campaigns have rather effectively communicated the ‘what of DevSecOps and AppSec automation, more awareness of the ‘how’ of DevSecOps is needed. TSP marketers need to design and propagate content on use cases focusing on the implementation challenges and suggested how-tos. Such content not only helps build trust and credibility but also allows segues for tech marketing to collaborate with security engineering. Some of these include practical guides on open source tool automation and sample automation scripts and libraries, data sheets on resource optimization through automation and handbooks on vulnerability remediation, just to name a few.

    This collaboration between marketing and sales and security would provide an opportunity for the former to get themselves well entrenched in the practical workings of the service or solution that they are responsible for positioning. Ironically, this also allows them to appreciate constraints that would prevent them from over- or under-committing business value to their prospects through their messaging. This is especially more relevant with the numerous myths that surround application automation and DevSecOps in general.

    The DevSecOps Rolodex

    In 2012, I had the opportunity to meet with one of the senior CISOs in the industry. After some initial small talk, I was introducing what we did and how we thought we could help his team. I was 70 seconds into what was my planned 180-second pitch when he respectfully stopped me, pulled out a rather impressive Rolodex from his desk and said, “I could point you to 15 companies in a 20-mile radius who could help me with exactly what you’ve offered me. I wonder if there’s any secret sauce?”

    Startled, embarrassed, I managed to gather my thoughts and moved to the final 30 seconds of the pitch, though with much hesitation. As luck would have it, he found little bits of the secret sauce. The meeting obviously did not go exactly as I had planned, but it didn’t go badly, either. However, it made me realize that our customers and prospects often know just as much—or even more—about our competition than we do. Everybody is selling, all the time. So, someone else has already made their 70-second pitch. Not everyone gets lucky enough to be given an opportunity for a pause! It’s up to us to find the secret sauce and make that close in the final 30 seconds.

    We are riding a very healthy wave of application security focus right now, and it’s paramount that technologists and marketers collaborate to identify and nurture their own secret sauce in their messaging and positioning. After all, this is what is going to keep the person at the other end of the table from reaching out to others in their DevSecOps Rolodex!

  • No More Hot Potato: How Collaboration is Key in Application Security

    No More Hot Potato: How Collaboration is Key in Application Security

    Technology is accelerating at an unprecedented rate and companies with little digital footprint or experience in application security are struggling to keep up. With more and more breaches and vulnerabilities being detected in applications, people are shifting blame like it’s a game of hot potato. But it doesn’t have to be that way.

    With Shifting Left Virtual Conference rapidly approaching, Rebecca Auguste sat down with the CEO of ShiftLeft, Manish Gupta, to discuss how developers and application security teams can better collaborate to increase application security efficacy. The two talked about ShiftLeft’s strategy, how innovation and security can be at odds with one another, adopting modern solutions and everything in between.

    What is ShiftLeft? 

    ShiftLeft is a next generation application security company. As companies are moving rapidly adopting the cloud, developing software ever faster so they can deliver features to their customers and drive ever increasing revenue, in that race we are starting to leave security behind because we are still using legacy tools. The idea is we need to shift left and we have to start fixing vulnerabilities as early on as possible in the process thereby reducing our cyber risk.

    Are innovations and security at odds with each other now? 

    Historically they have been. Use of legacy technologies in a modern pipeline forces customers to choose between being agile delivering feature functionality faster or getting better at security. At ShiftLeft we are starting to show through our customer successes that that choice doesn’t have to be that way. We can become more agile and we can become more secure.

    Here are some important statistics from ShiftLeft customers:

    1. If you’re doing automated enforcement in ShiftLeft you are fixing 91.8% of the vulnerabilities
    2. If you’re not doing automated enforcement but you’re using a modern solution like ShiftLeft you’re fixing 58% of vulnerabilities in the first sprint.
    3. If you’re still stuck with a legacy solution, your team isn’t fixing 60% of the vulnerabilities ever – forget if it’s the first, second or third sprint. It becomes technical debt. 

    So why aren’t people adopting modern solutions like ShiftLeft and ditching legacy solutions?

    Legacy solutions ask developers to slow down because they have to take a few hours to go scan and dump a long list of vulnerabilities. As the developer, seeing hundreds of vulnerabilities is like a deer in the headlights. Because it’s a mountain of work, it’s easy for developers to want to ignore the problems. The question shouldn’t stop at “what are our applications consisting of?” The real problem gets solved when we start asking what do our applications contain and what vulnerabilities do they have that can be exploited, therefore how quickly can we fix them. It’s all about moving to be proactive, not reactive.

    How can development and security teams better collaborate to increase the efficacy of security with applications and software? 

    It’s extremely important for us to realize that developers are not responsible for security. Developers are measured, they are compensated to deliver feature functionality on time and to provide that feature functionality with minimum bugs. But bugs are not vulnerabilities. There is a lot of talk in the industry that developers should become responsible for application security. We aren’t there today but we can eventually.

    There are two important application personas: 

    • Application security: Application security has a mile wide and inch deep knowledge of applications and who is compensated on app security improvements.
    • Developers: Developers have a mile deep but inch wide knowledge of software because they are so focused on their own code.

    Both personas are required because application security cannot fix vulnerabilities in applications, the developer must do that. But developers aren’t going to want to do that unless that work is prioritized by application security.

    Key takeaway? Collaboration is essential to application security.

    We need to create a workflow that allows application security to meet their end goals such as: What are the vulnerabilities of an application? What are the critical vulnerabilities? How can I provide these vulnerabilities to the developer in a developer workflow without asking them to go to a different console so they can fix vulnerabilities as quickly as possible? We need to start seeing a workflow that allows both application security and developer personas to work collaboratively to improve application security.

    Shifting Left 2.0 is a two-day virtual conference taking place from 9 a.m. to 2 p.m. PDT on June 22nd-23rd that dives deep into application security in the modern tech space. To register for free and to check out the full agenda, visit the Shifting Left 2.0 website.

  • How to Analyze Your Code for Security Vulnerabilities

    How to Analyze Your Code for Security Vulnerabilities

    Shifting Left 2.0 is a two-day virtual conference taking place from 9 a.m. to 2 p.m. PDT on June 22nd-23rd that dives deep into application security in the modern tech space. Security experts share insights on topics ranging from how to measure AppSec success to what role AppSec plays in digital transformation. Software developers, security engineers, C-level business leaders and more can all benefit from the lively tech conversations at this free virtual experience. 

    Vickie Li, developer evangelist at ShiftLeft, teases her session at Shifting Left 2.0 in the Q&A below. Vickie and Suchakra Sharma, staff scientist at ShiftLeft, describe how to effectively review code for vulnerabilities and present tactics for performing an effective security code review on your applications on Wednesday, June 23rd from 10:10 a.m. to 10:40 a.m. PDT.

    You can find the full agenda and register for free at Shifting Left 2.0.

    To start off, why don’t you tell me a little bit about your role as a developer evangelist at ShiftLeft?

    My job as a developer evangelist is to help developers write more secure code. Here at ShiftLeft, we build and support ShiftLeft CORE, a security tool that helps developers find vulnerabilities in their code through SAST, SCA, and secret scanning. But a big component that goes into building secure software is to understand and remediate the vulnerabilities found by these tools. My goal is to help developers build more secure applications by learning the security fundamentals they need to write secure code and use security tools effectively.

    Your session is titled, “Intro to Code Analysis,” so I am curious what are some of the most effective ways to analyze your code for security vulnerabilities?

    I am probably giving away a bit of a spoiler here for my session with Suchakra. The most effective way of finding vulnerabilities in code is to use static code analysis, or to find security issues by analyzing source code. Techniques like dynamic analysis and penetration testing excel at finding exploitable vulnerabilities but often miss a large number of security issues. Static analysis, on the other hand, tends to be much better at finding as many vulnerabilities as possible.

    But conducting a manual code analysis on every single line of code is inefficient and not feasible in most cases. In this case, utilizing a SAST tool to scan the application and then validating the results afterward using manual code review would be the best action plan. 

    Code is really at the heart of building secure applications. With that in mind, how beneficial is it for developers to have a security mindset when writing code? 

    It is extremely crucial for developers to keep security in mind when building software. Security is a team effort by everyone: application security engineers, system administrators, managers, architects, and analysts. But when dealing with application security, developers are the ones who write vulnerabilities into code, and developers are the ones who have to fix vulnerabilities when they are found. So as developers, if we can keep security in mind during the development process, we can prevent vulnerabilities from being introduced into the code base, saving ourselves and our colleagues time and headache down the line.

    What type of security training or continuous learning practices should dev teams implement to help secure the code they write?

    Learning about security continuously is key to building secure applications. Developer security education needs to be efficient, engaging, and easy to absorb, and we need to introduce security training in a way that is relevant to everyday development work. By identifying security issues in a developer’s code, we can provide the context of the security issue and demonstrate the real-life importance of best practices.

  • DevOps Connect at RSAC 2021: Insightful Talks, Live Q&A, Workshops, Pilates and More

    DevOps Connect at RSAC 2021: Insightful Talks, Live Q&A, Workshops, Pilates and More

    We are excited to announce the return of DevOps Connect: DevSecOps Virtual Summit on May 19, as part of the RSA Conference 2021. This year, internationally recognized speakers will take a deep dive into “Securing the Cloud Native World.”

    DevOps Connect is a full-day event, featuring four different content tracks, with more than 50 speakers, including keynote presentations, demos, insight talks and featured sessions.

    The agenda features a mix of topics, including cloud security, CI/CD, Kubernetes, GitOps, AppSec, security risks, shift left, open source, case studies covering DevSecOps and more. Attendees will learn how the finance, manufacturing, healthcare and hospitality industries are securing their cloud environments, and how to better secure and monitor their systems.

    DevOps Connect 2021 Lineup

    DevOps Connect 2021 features an exceptional lineup of the most prominent and respected security and DevOps leaders, including:

    • Featured keynote speaker: Christopher Krebs, former director of the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA), and co-founder of Krebs Stamos Group LLC
    • Chenxi Wang, founder and general partner at Rain Capital
    • Allan Friedman, director of cybersecurity initiatives at National Telecommunications and Information Administration in the U.S. Department of Commerce
    • John Willis, senior director of Global Transformation Office at Red Hat
    • Cyndi Gula, managing partner at Gula Tech Adventures
    • Alessandro Vozza, principal software engineer at Microsoft
    • Caroline Wong, CSO at Cobalt
    • Thomas Krane, principal at Insight Partners
    • Charles J. Kolodgy, principal at Security Mindsets LLC and analyst at Accelerated Strategies Group
    • Nisha Kumar, open source engineer at VMware
    • Mike Rothman, president at DisruptOps
    • Dave Howell, VP at ZeroNorth
    • Maciej Mensfeld, senior product manager at WhiteSource
    • Matt Wilson, senior product manager at GitLab
    • Erkang Zheng, founder and CEO at JupiterOne
    • Philippe Humeau, CEO at CrowdSec
    • Jennifer Czaplewski, director of product security at Target
    • Al Sargent, senior director of product at InfluxData

    Former CISA director Christopher Krebs, our featured keynote speaker, will be answering questions from the audience during a live Q&A.

    Workshop Friday

    We are also hosting Workshop Friday, as we wrap up the RSAC 2021, offering live workshops designed to be as interactive and hands-on as possible with experts from Google, JupiterOne, Sysdig and Sonatype. These workshops provide professional guidance and training on a variety of topics, including Site Reliability Engineering (SRE), AWS cloud security and protecting against supply chain attacks. On May 21, attendees will have the opportunity to interact with the experts, share their process, get immediate feedback and personal assistance. Each workshop will be live-streamed through our online platform at no cost to attendees. We have limited spots available. Seats are reserved on a first-come, first-served basis. To save your spot, visit the Workshop Friday website.

    A Unique Virtual Environment and a Few Surprises

    The virtual environment features an auditorium with different tracks where attendees can watch the sessions by industry experts. There will be an expo hall lined with booths featuring interactive chats and downloadable resources. The expo hall will be open throughout the event, giving attendees the opportunity to chat with sponsors, including GitLab, Prisma Cloud by Palo Alto Networks, Sonatype, WhiteSource, Sysdig, JupiterOne, Snyk and more.

    We have a few surprises planned to make this year’s DevOps Connect extra special. Take a break between presentations, grab your yoga mat and enjoy a Pilates class by a certified instructor, dance to the music of our featured DJ and check out how to make a delicious cloud drink by a professional mixologist. You can also participate in a raffle to win a copy of “You Can Stop Stupid” by Ira Winkler, author and president at Secure Mentem, and a copy of “Security Yearbook 2020” by Richard Stiennon, industry analyst at IT-Harvest.

    DevOps Connect 2021 offers the best of a physical environment in a virtual context combined with the advantages and convenience that a virtual environment offers.

    Registered attendees will receive a link to access the virtual environment on-demand. To check out the full agenda and to register, visit the DevOps Connect website.

  • Is Low-Code Development a Security Risk?

    Is Low-Code Development a Security Risk?

    According to Gartner, the worldwide low-code development market is projected to be $13.8 billion in 2021, a whopping increase of 22.6% from 2020. Gartner also predicts that the surge in remote development during COVID-19  will continue to boost low-code adoption, despite budget cuts and efforts to optimize cost.

    Low-Code’s Popularity Among Professional and Citizen Developers

    Low-code is no longer the new kid on the block. From simple dashboards to complex applications, low-code applications are becoming more and more diverse, with mainstream adoption in the enterprise world. In essence, low-code is a visual paradigm of application development that involves drag-and-drop of pre-built components and integrations resulting in fast, easy and less-error-prone development.

    The advantage of low-code is that it enables users from a non-traditional development background to participate in the app development process, thus democratizing development and accelerating project timelines. It also narrows the demand-supply gap that arose as organizations catered to ever-rising digitization needs with limited resources and developer scarcity. Many low-code platforms make it easy for citizen developers (business analysts, line-of-business users, junior developers, for instance) to build applications while drastically reducing delivery time compared to traditional coding methods.

    But citizen developer productivity and speed are not the only benefits of low-code development. Today, low-code platforms also come with capabilities purpose-built for professional developers from enterprise IT teams to ISVs. These platforms are hardened for enterprise use, are able to leverage the scalability and security needs of a complex application and have integration capabilities mature enough to seamlessly fit in with existing tools and technologies. During the COVID-19 pandemic, many businesses reinvented themselves through adoption of low-code platforms and applications that helped them adapt to the sudden shift to a remote work scenario and enable the necessary modern application needs that came with it.

    Security Challenges with Low-Code and Remote Work

    Compared to traditional development, low-code involves a variety of personas working together to build applications while dealing with automatically generated code, ready-made components and built-in default configurations. This shift in environment revealed some unique challenges that need to be addressed. There are a few common security challenges with remote teams building on low-code.

    Application Development and Remote Team Collaboration

    • Lack of security awareness: Low-code users come from both business and tech backgrounds. Some practitioners aren’t familiar with application security best practices and lack awareness and understanding of potential vulnerabilities and security holes.
    • Platform access and admin controls: Low-code is deployed centrally and available for users across an enterprise via browser access. This introduces a risk of network intrusion; providing access to unauthorized developers and opening up greater permissions to users that do not need it when accessing the platform remotely.
    • Code repository and team collaboration: Low-code platforms must ensure that the automatically generated code can committed to enterprise-sanctioned repositories. This code access shouldn’t be misused, and ought to have sufficient protocols in place for code control and upgrades.

    Code Generation and DevSecOps Best Practices

    • Securing custom code: Low-code tools allow for writing custom code to extend and enforce platform coding guidelines and design patterns to protect sensitive data from unauthorized access.
    • Adhering to secure release practices: Integration with the existing enterprise CI/CD pipeline is important so that dev teams can extend the same release governance protocol to the auto-generated code before going to production.

    End User Application Access and Data Protection

    • Preventing malicious attacks: Today, both web and mobile apps are becoming constant targets for security breaches. Automatically generated code, and citizen developers working remotely, can make low-code applications more prone to vulnerabilities. Platforms should generate apps that are fully protected against phishing attacks, SQL injections, brute force attacks and DOS attacks.
    • Secure data and application access: Low-code platforms should provide a comprehensive access control mechanism preventing unauthorized access to data and app functionality. With remote teams accessing apps from anywhere, at any time and from any device, data breaches can be prevented with the right controls in place.

    Low-Code and Security – The Future of Development

    As enterprises and ISVs turn to low-code for more serious use cases, the larger question still remains. Can low-code platforms enable modern development teams to deliver applications faster, while still enabling a secure and tightly governed environment?
    The answer is, yes, they can! However, development teams must consider the following security checklist when considering low-code platforms:

    1. The chosen low-code platform must be set up within an enterprise secure DMZ or secure private cloud, and must effortlessly pass cybersecurity clearances.
    2. The platform must enforce best practices in programming (coding conventions, design patterns and data encryption) for automatically generated code as well as custom code written by the developer, facilitating easier integration with existing CI/CD processes and tools.
    3. The platform must offer full protection against the top 10 OWASP vulnerabilities for web and mobile apps, and have third-party certifications to guarantee code quality and security. Also, organizations should ensure that there are no vulnerabilities in their chosen platform’s binaries, as well as all third-party dependencies (including open source libraries) as listed in the CVE library.
    4. The solution must support multiple authentication providers (database, LDAP, AD, SSO, SAML, Open-ID, multifactor, biometric) to build applications with strong user security. For user authorization, ensure support for both coarse-grained as well as fine-grained access control policies to protect various aspects of the application based on RBAC.

    Development teams can embrace low-code technology while ensuring security best practices are in place. Low-code is here to stay, and with the right platform, enterprises and ISVs can make sure security is shifted left and addressed by developers much earlier in the development process. The result is a highly productive, remote workforce churning out applications that are modern, scalable and secure.

  • Is Open Source More Secure Than Closed Source?

    Is Open Source More Secure Than Closed Source?

    There’s no getting around the fact that security is one of the most essential factors in day-to-day operations for most software developers. From proprietary code to sensitive customer data and everything in between, there are hundreds – if not thousands – of crisis scenarios that can result from gaps in security.

    Data security is an issue that every company faces, no matter how large or small. Developers look for security solutions that follow today’s data and application security best practices in order to reduce risk and provide the most secure experience possible to the end user.

    A common debate among both users and developers is whether open source software is more or less secure than closed source alternatives. While there are a variety of different schools of thought as to what makes for a truly secure environment, there is good reason to believe that open source software is the superior option for those looking to prioritize security.

    While open source code may not be inherently more secure than its closed source brethren, here are a few reasons why it almost certainly can be — so long as you take the right approach.

    Open Source Offers True Transparency

    Both well-established tech giants and up-and-coming startups work with some of the brightest minds in the development community to bring valuable proprietary software products and services to market. At the end of the day, however, users have no choice but to trust what a vendor says about how a particular piece of software actually “works.” Since you can’t see the code itself, there’s no way to really verify whether or not what you’re being told – about features, functionality and security – is accurate.

    This can be problematic for a host of reasons—not least of which being the threat of potential security flaws. A company might boast about its commitment to user security and privacy through savvy public relations and product marketing efforts. But, by no means does this provide the user with anything more than lip service if the code doesn’t measure up; even if it’s rock-solid, the question of “How truly secure is this?” can never be answered with confidence.

    Open source software offers greater transparency to the teams that use it; visibility into both the code itself and how it is maintained. Giving organizations access to the source code allows them the opportunity to evaluate the security of the code for themselves. Additionally, users have more visibility into how and what changes are made to the code base, including the pre-release review process, how often dependencies are updated and how developers and organizations respond to security vulnerabilities.  As a result, open source software users have a more complete picture of the overall security of the software they’re using.

    Open Source Encourages Community Input

    Another major benefit is found in the communities which drive the growth and development of open source software. The vast majority of open source software is backed by communities of forward-thinking developers, many of whom use the same software they build and maintain as a primary means of communicating with team members. Open source developers and the communities around the software value users’ input to a significant degree, and many user suggestions end up getting incorporated into new versions. The community involvement and investment ultimately leads to many more responsible vulnerability disclosures than would likely occur if the software was closed source.

    When vulnerability reports do occur, they tend to be more detailed because the code is open source; often, they even come with code suggestions for how to remedy a given issue. This is incredibly helpful and can dramatically speed up patching the vulnerability, as it allows developers to move faster without spinning wheels and getting stuck in the diagnostic process.

    Faster Security Updates

    Within the framework of closed source software, users are at the mercy of the companies behind those products or services when it comes to receiving software updates―open source tends to be a different story. Fully open source projects even allow users and developers to take things into their own hands and contribute feedback and fixes, should they choose to do so.

    More often than not, updates and fixes for high-profile closed source applications involve a great deal of complex planning. If it’s not in the budget, for example, users may not see a new update for weeks, months, or even longer—security flaws or not.

    In most circumstances, open source tends to move faster than closed source when it comes to iterating and releasing new versions. This is true for a handful of reasons, including the fact that open source software tends to have more eyes on the source code at any given time, as well as a community-driven interest in bettering the product whenever possible. If a significant security flaw is uncovered, users may even choose to fix the code themselves, resulting in a level of control that can never be achieved in a closed source environment.

    Open Source Offers Flexibility, Collaboration and Enhanced Security

    An open source methodology, in and of itself, is no guarantee of security, but it does offer teams greater insight and control over the software they rely on. And as open core and source-available software are more broadly adopted, they offer a wealth of opportunities to build incredibly secure environments without sacrificing usability for end users or support from official maintainers.