devopsy.kinsta.cloud

Tag: devsecops

  • Low-Code and DevOps: Friends or Foes?

    Low-Code and DevOps: Friends or Foes?

    What does low-code mean, and who is it really for?

    Over the last few years, I’ve seen many articles associating “low-code” with “citizen developers” or with people who don’t have deep development skills. Users can arrange visual elements, or fill in forms with key information and publish the result as an application.

    But tools for citizen developers are only one part of the low-code story. There is also a growing number of tools for professional developers, and I want to talk about those, too.

    Both citizen developers and professional developers have a role to play in application development and automation projects, and low-code has something to offer both of them.

    Low-code is Not a Market, it’s an Approach

    Low-code does mean providing visual and graphical tools and simple frameworks that mask more complex coded operations, so the application designer does not have to directly touch the code that performs desired operations. These apps are naturally limited, as the resulting application can’t be highly customized if you can’t touch the code.

    With these kinds of visual tools, anyone can create a simple application within the limits of the tool. But when we pull back and look at what is needed to create larger, more complex applications – ones that need to communicate with other enterprise systems, or need extensive customization, or cross organizational boundaries, or need to pay attention to governance requirements, for example – the visual-only approach is frequently insufficient. In complex cases, developer expertise is often needed, and developers have to get “under the hood” to tinker with code.

    There is no “low-code market.” We are bringing tools to people who need them to develop specific projects. A comprehensive low-code approach to application development and automation means offering both visual programming and coding capability. For usability reasons, these tools are clearly separated and presented to the development team in a way that allows citizen developers to work on certain elements and developers to work on others, all on the same platform.

    We know that it’s possible to serve professional developers with low-code, too. A low-code approach also includes drag-and-drop tools that developers can use – for example, to develop APIs, or to integrate the application with other systems, or to customize front-end interfaces. Of course, when code is required, developers should be able to use their own tools and frameworks and not be limited by low-code tools. Platforms that offer a hybrid approach are likely to be most useful to mixed-skills development teams.

    The Hybrid Approach

    Strictly low-code tools can serve simple automation use cases. More broadly, automation platforms offer a hybrid of low-code and coding capabilities for more complex automation use cases.

    For critical enterprise applications, both business and developer inputs are usually needed. Having tools for both of them means not leaving anyone out.

    Low-code tools will continue to become more mainstream. Low-code is not a fad or a passing trend, but a quiet revolution that will see greater incorporation into more business tools.

    Here Come the Digital Natives!

    More vendors are offering low-code tools for digital process automation, business intelligence, robotic process automation, identity management and data integration, to name just a few.

    As automation platforms and other low-code tools mature, a greater number of people are getting used to working with them. Developers are less hesitant about incorporating non-developers into their teams, as everyone gains a better understanding of the benefits of these platforms.

    The younger generations entering the workplace today are digital natives. They are fearless about diving into technology and working hands-on. So, these low-code tools are ready for them, and they are ready to put them to work.

    Low-code is breaking down technical barriers to work in the automation space, making smooth collaboration between business and development easier.

    Low-Code Can Be a Double-Edged Sword

    Automation and development teams are also becoming more aware of vulnerabilities and compliance issues as citizen developers roll up their sleeves and join the technical team.

    Low-code tools are a double-edged sword. They facilitate teamwork, but issues with security and data governance may not be top-of-mind for non-developers. If you have a big team working on automation and/or application development and delivery, the need to build in governance becomes even more important.

    Using a shared platform will help manage and mitigate these issues with security and governance. This will become even easier as the platform tools evolve and mature, so DevOps teams can use them to help mitigate some of these issues.

    Does Low-Code Have a Place in DevOps?

    We are definitely seeing the impact of low-code on development environments and DevOps. Remember, low-code started with small applications, and while DevOps-style teamwork and workflows may not be needed there, as the use of low-code platforms becomes the norm for critical enterprise projects, DevOps will be a necessary part of the mix. This is where low-code is having a more obvious impact; Agile methodologies using low code platforms for iteration, for continuous improvement and for continuous delivery. These applications aren’t one-and-done. They need to be maintained, improved and delivered, again and again.

    Low code isn’t going away. On the contrary – it’s going everywhere.

  • DevSecOps: Rethinking and Reengineering Cloud Security

    DevSecOps: Rethinking and Reengineering Cloud Security

    Organizations are embracing the cloud to modernize legacy applications, create more resilient business infrastructures and to support remote work. In fact, Deloitte’s “TMT Predictions 2021: Cloud Migration Trends and Forecast” report suggests that, spurred by this growth, cloud revenues will likely continue to remain above 30% through 2025. While cloud migration is predisposed to embrace an agile development methodology enabled with DevOps, many organizations still leave themselves open to risk when modernizing and migrating applications to the cloud by neglecting to embed security into their development operating model, architectural design and processes.

    When migrating to the cloud to modernize applications, DevOps and DevSecOps, as an architecture process, can enable organizations to rethink and rearchitect the security model with a “security by design” approach. If done right, organizations stand to create more secure and agile applications that balance the need for continuous releases in an evolving threat landscape with building customer trust.

    DevSecOps Requires a New Operating Model

    DevOps is a demonstrated approach to achieving better value, sooner, from IT programs and is seeing new developments in an increasingly distributed work environment. Previously, organizations may have relied on a shift-and-adopt strategy for incremental cloud replatforming. But, today’s rapidly shifting business strategies demand fast reaction time and resilient solutions, as well as flexible and agile solutions supported by DevSecOps to help development and security move at the same pace as the business.

    Importantly, DevSecOps requires an integrated team of cross-skilled cloud and cybersecurity specialists working under a shared operating model. A modernization and migration center of excellence (CoE), often led by the digital transformation leader, can help bring together cloud and cyber specialists from across the business with external cloud service providers via a shared responsibility model. Through collaboration, cross-teaming, cross-skilling and a shared operating model across cloud developer and security functions, organizations can achieve better outcomes.

    Embracing “Security by Design”

    DevSecOps, then, is about more than moving existing security processes earlier into the development process. It is about elevating, embedding and evolving your organization’s risk response, as well as rethinking and rearchitecting the way applications are designed with security as a guiding factor in the architectural decisions. Secure by design means setting up a whole DevSecOps capability to make sure security is embedded early on in application architecture design and then further safeguarded through strategies like segmentation, zero trust and attack surface management.

    Before the migration begins, DevSecOps would have developers and security specialists considering data flows, functional requirements and work streams related to workload protection, secure landing zones, operating model, network segmentation, access/controls to be implemented in a zero trust environment, attack surface management and more. An organization, for example, might use microservices to segment application access for internal versus external users to achieve enhanced security through system design.

    DevSecOps Requires Process Innovation

    DevOps and DevSecOps bring the security and application teams together with shared processes and communication to quickly, securely and efficiently roll out products from concept to production at pace. During the pandemic, teams have pushed their use of communication and collaboration tools to better support distributed teams, including the use of ChatOps, to enable real-time knowledge sharing and knowledge management, increased DevOps automation through incorporation of cloud artificial intelligence (AI)/machine learning (ML) services and reimagining traditional roles to embrace more of an IT-as-a-service operating model.

    DevSecOps

    As DevOps continues to shift left beyond DevSecOps to embrace operations, governance, and customer support, developers will need to work on increasingly integrated teams. These foundational communication leading practices can be valuable as a model for agile working across functions.

    Rethinking Cloud Security and Development

    DevSecOps can help support cloud migration and agile development programs that require speed and resilience by rethinking the development operating model, architecture approach and collaborative processes to improve security and compliance and enhance customer trust. Security specialists must understand the demands placed on developers for fast migration and continuous releases and developers need to work with cyber professionals collaboratively to make applications designed to be secure and resilient. A security-by-design approach to cloud cyber collaboration can help organizations to rethink and re-engineer their DevSecOps approach. Security specialists should also work toward making their services easily consumable in the DevOps process to enable frictionless security.

    Vikram Kunchala, Deloitte’s Cyber Cloud leader and Principal, Deloitte & Touche LLP, and Amod Bavare, Deloitte’s Global Cloud Migration and Modernization leader and Principal, Deloitte Consulting LLP contributed to this article.

  • How To Address DevSecOps Skills Shortages

    How To Address DevSecOps Skills Shortages

    “If it’s scarce, it drives the price up,” said McAfee director of systems engineering Sahba Idelkhani. And DevSecOps talent is scarce, and expensive.

    Restrictions on international travel are having an effect on immigration in some countries, notably Australia. But there’s practically nothing employers can do about that.

    But some aspects of the supposed skills shortage are, in part, self-imposed. One example is recruitment ads that specify “5+ years’ experience required” (or something similar) when that level of experience is only a desirable characteristic.

    Such practices don’t just restrict the field of candidates for that particular vacancy, they also make it hard to find entry-level positions. If candidates can’t get a foot in the door, how can they gain the experience that employers say they want?

    DevSecOps Change is Needed

    Idelkhani suggests that organizations need to change their hiring practices and put more effort into reskilling existing employees.

    In particular, if you’re looking for DevSecOps people, he suggests it’s better to teach developers about security than it is to bring security specialists (who are also in short supply) up to speed about development. The result is less rework, reduced risk and shorter development timelines.

    However, there is a risk that security specialists will tell developers what they did wrong. Proactively educating developers about security is a more productive approach.

    Cloud Academy is one of many sources for online security training courses and includes hands-on labs, sometimes involving the same tools that criminals use to breach security. Other tips Idelkhani offered include adopting a “build secure” mindset to reduce the security effort needed after systems have been created.

    A similar perspective can be applied to entry-level positions.

    Idelkhani has hired new graduates, even though it requires effort to guide and train them to the point of being productive.

    He has even adopted this approach with experienced people that have no background in security, including a former CTO and mobile developers and a pre-sales engineer.

    Revamp job descriptions so more people can apply, urges Idelkhani, as aptitude and skill are more important than specific experience, which can be taught.

    For example, instead of a large financial services organization recruiting someone with experience in incident response for cloud systems, it would probably be better to hire an incident responder and then sponsor their cloud training, he suggests.

    Furthermore, a diversity program increases the supply of candidates, quite apart from the other benefits it may bring.

    DevSecOps Training

    Employers sometimes suggest training is a waste of time and money because people simply take their new skills elsewhere in search of higher pay.

    But Idelkhani reports that his staff turnover has, in fact, fallen over the last three years, and no one has left after being trained.

    He puts this down to establishing an “emotional connection” between employee and employer, at least in part.

    However, organizations do have to accept the need to pay people what they are worth as they master new skills. But standard HR practices don’t suit skills development situations, he warns.

    People usually won’t move from their current role or company for a 10% to 20% pay raise, Idelkhani said, but would be more willing to do so for the 200% to 300% increase that comes from being considered an accomplished worker rather than a mere trainee.

    At McAfee, he is able to argue for ‘pay for value’ raises for his team; that task is generally harder at larger organizations, he said.

    “It needs a rethink [of] HR practices,” he added.

    Planning

    Substantial raises tend to require approval from higher up in the hierarchy, and that requires a clear justification for the increase. He suggests this should be done in terms of the capabilities that are being built, not based on the numbers alone.

    Managers should look at the skills they are going to need in order to deliver on the business’s strategic goals and plans, and decide how best they can be obtained. An expected DevSecOps vacancy might best be addressed by hiring a cloud developer and training them in the necessary security skills, or by retraining a person with potential who is already on the payroll.

    “It’s a long-term process,” though, that requires a lot of management effort, Idelkhani said. Using this method means identifying people’s interests and skills, aligning them with company goals, identifying the skills gaps and then developing those needed skills. This requires a training budget and getting one approved means having clear plans.

    But once you have shown the value of this approach, senior management is less likely to question it in the future.

  • 42Crunch API Security Platform Now Available On-Premises

    42Crunch API Security Platform Now Available On-Premises

    42Crunch has announced that the scanning tools it provides to enable DevOps teams to secure application programming interfaces (APIs) can now be deployed in on-premises IT deployments.

    Previously only available as a cloud service, the 42Crunch API Security Platform has also been updated to provide expanded support for the OpenAPI specification for REST interfaces defined by the OASIS standards body.

    Finally, the 42Crunch API Security platform now allows IT teams to share collections of APIs among specific teams and users with different levels of access in addition to providing integration with third-party identity management platforms.

    Dmitry Sotnikov, chief product officer for 42Crunch, said the on-premises edition of the API scanning platform will make it possible for IT organizations, including those that require all the platforms they run to be deployed in an IT environment, to exercise more control over and extend their DevSecOps workflows to include scans of APIs.

    Cybercriminals are increasingly targeting insecure APIs because they potentially provide access to a trove of data, Sotnikov noted. Those same APIs also enable cybercriminals to compromise an entire software supply chain, Sotnikov added.

    At a time when more organizations are deploying APIs, thanks to the rise of microservices, it’s apparent there is a greater need for a tool that dynamically scans APIs for vulnerabilities before they are deployed, said Sotnikov.

    In general, Sotnikov said IT organizations are becoming more sophisticated in their approach to securing software. Ford Motor Co., for example, is using the 42Crunch API Security Platform to secure both internal and external APIs, Sotnikov said. 42Crunch claims its revenues increased 900% in 2020, with more than 150,000 users of the platform.

    As organizations of all sizes become more dependent on software, cybersecurity teams are now reviewing how that software is constructed. Of course, responsibility of security is still shifting left as part of the overall transition to DevSecOps best processes, but Sotnikov said cybersecurity teams still want to verify for themselves that whatever software is deployed is secure. IT organizations are moving away from a “whack-a-mole” approach to security as they embrace DevSecOps, Sotnikov added.

    Unfortunately, APIs don’t always receive the level of attention they deserve. Many developers still tend to view them as an afterthought, and once deployed, it’s not uncommon for APIs to languish for years without being reviewed or updated. Making sure APIs are secure requires dynamic scanning processes to be baked into DevOps workflows if organizations want to ensure the integrity of their software, said Sotnikov.

    APIs are, of course, everywhere now. The days when a handful of APIs were exposed to share data with a limited number of customers and partners are long over. There are almost no applications built and deployed today that doesn’t expose myriad APIs. Cybersecurity teams obviously can’t keep pace with the rate of change being made to those APIs, as new ones are added and others updated or replaced. The onus for securing all those APIs is, now more than ever, clearly on the DevOps team.

  • Red Hat Survey Reveals More Confidence in Open Source

    Red Hat Survey Reveals More Confidence in Open Source

    A recent Red Hat survey revealed how DevOps teams increasingly depend on open source to support their shift to cloud-native environments and digital transformations, and to maintain security in these highly distributed environments.

    Based on a survey of 1,250 IT professionals, Red Hat maintains that the survey respondents — from organizations that were Red Hat customers — were unaware that Red Hat sponsored the study to help avoid “biased or influenced responses,” Red Hat said in a statement. 

    During the past two years, the number of organizations that deemed open source necessary for their digital transformations increased 11% to 53%, representing the majority of the respondents’ organizations. 

    The vast majority (87%) of the respondents considered open source to be “more secure” than or “as secure” as proprietary software, while 84% indicated that enterprise open source “is a key part of my organization’s security strategy.”

    While the survey reflects open source’s importance for security for IT professionals in DevOps, its support of the overall business mission is key, as well, says Momodou Jaiteh, application security consultant at nVisium, an application security provider.

     “Information security is about reducing and mitigating risk to enterprises, from technology, people and process perspectives. It helps enable the business to operate securely in the best interest of its shareholders and customers,” Jaiteh said. “Thus, security typically plays a supporting, [but] nonetheless critical role in the success of the business, especially in a digitally connected world.” 

    Open source software often helps businesses reduce overhead cost in delivering services to their customers through reduced time to market, Jaiteh said. One major additional advantage is “visibility and input from a lot of different people,” Jaiteh added. 

    “Greater visibility often translates to more observing eyes on all aspects of the open source software, which often translates to better security. This is even better for mission-critical software that deals with sensitive information, such as cryptographic algorithms, etc.,” Jaiteh said. “It is not a surprise to see open source used more in infrastructure modernization, because as we move to DevSecOps models of software delivery, infrastructure often is the bottleneck. Therefore, solving for infrastructure helps developers focus on aspects that are unique to their business.”

    While survey respondents ranked improving collaboration between IT and business stakeholders to achieve a digital transformation as their highest priority, implementing cloud technologies or infrastructure ranked second. Infrastructure modernization is thus seen as a prerequisite for a full digital transformation, said Dirk Schrader, global vice president, security research at New Net Technologies (NNT), a cybersecurity and compliance software provider.

     “Open source plays a vital, pivotal role in almost all digital trends driving any industry sector today,” Schrader said. “Cloud computing or containerization is rooted in open source technology, many development libraries are open source, and the market for open source solutions has been a model for servitization; the changes in one’s business model away from selling a product to selling a service, or an integration of service, and product that focus on additional value-add for the customer.”

     For security, the main advantages consist of being able to review, inspect and audit “each and every piece of code,” Schrader said. 

    “The ability of open source to be a base for services makes it the natural companion for any digital initiative,” Schrader said.

  • Sysdig Adds CSPM Module to DevSecOps Platform

    Sysdig Adds CSPM Module to DevSecOps Platform

    Sysdig today announced it added a cloud security posture management (CSPM) module to its Sysdig Secure DevOps Platform for monitoring application performance and security to enable IT teams to continuously detect threats.

    Pawan Shankar, director of product marketing for Sysdig, said this CSPM capability is based on an open source Cloud Custodian tool that enables IT teams to define rules for accessing cloud infrastructure. In addition, the tool enables IT teams to collect utilization metrics that could be used to turn cloud resources off when they are not being employed. IT teams can now also automatically discover all cloud services being employed, including identifying which ones are misconfigured or might have compliance and regulatory issues that need to be addressed, via a software-as-a-service (SaaS) platform.

    The overall goal is to help reduce the friction that organizations encounter today as they embrace DevSecOps best practices, added Shankar.

    Sysdig is making its CSPM offering available for free, for one account, to encourage DevOps teams to make use of a CSPM capability along with Sysdig’s open source Falco threat detection capabilities. Sysdig today also announced that it extended its implementation of Falco to consume audit logs created on the Google Cloud Platform (GCP). Sysdig donated Falco to the Cloud Native Computing Foundation in 2018. More recently, Sysdig also contributed a sysdig kernel module, along with libraries for the Falco security platform for Kubernetes, that runs in the extended Berkeley Packet Filter (eBPF) microkernel to further improve Linux security.

    The free tier includes a daily check against CIS benchmarks as well as support for inline scanning of up to 250 container images per month running on either the Fargate or Elastic Container Registry (ECR) services provided by Amazon Web Services (AWS).

    Sysdig has been making a case for the convergence of traditional IT monitoring functions and security for several years now. In the wake of some recent high-profile breaches involving software supply chains, the company is betting that more DevOps teams will soon be revisiting how their software supply chains are managed at a time when it’s become easier for malware to move laterally across an entire IT environment. In fact, Sysdig cited research that estimates that malware moving laterally through an organization is involved in 70% of cyberattacks.

    Of course, with the rise of applications based on microservices, the average IT environment is about to become a lot more integrated, which naturally makes it easier for malware to move laterally. IT organizations now require greater visibility across an entire potential attack chain to combat those threats, Shankar noted.

    As DevSecOps continues to evolve, the relationship between developers and cybersecurity teams is also clearly evolving. Now that developers are being held more accountable for cybersecurity, many of them are gravitating toward tools that can be easily integrated within the context of a larger DevOps toolchain.

    It remains to be seen exactly how security tools will be integrated within those tool chains, but for DevOps teams that already rely on Sysdig to monitor their IT environments, the ability to access a raft of additional security services is only a few mouse clicks away.

  • Solvo Automatically Crafts Cloud Security Policies

    Solvo Automatically Crafts Cloud Security Policies

    Solvo today announced general availability of a namesake tool that automatically creates a least-privilege policy and applies it to application workloads deployed in the cloud.

    Previously available only as a private beta, Solvo will also continually analyze a workload after it’s been deployed to enable IT teams to adjust security policies as additional updates to an application are made.

    In addition, Solvo is making available for free the Solvo Security Genie, which IT teams can use to identify misconfigurations, excessive permissions, privilege levels and third parties that may have access to accounts on the Amazon Web Services (AWS) public cloud.

    Shira Shamban, Solvo CEO, said the primary reason there are so many cloud security issues today is because developers – that lack cybersecurity expertise – are being asked to define policies. Solvo removes that burden by analyzing a workload and creating a cybersecurity policy before applications are deployed in the cloud. That cybersecurity policy can then be automatically applied by the developer.

    Shamban said that approach will reduce a lot of the DevSecOps tension that organizations are currently experiencing as they try to shift responsibility for cybersecurity further left toward developers. While no developer deliberately sets out to deploy an insecure application, shifting responsibility for cybersecurity to a developer who doesn’t really understand what’s required creates a lot of additional stress.

    The Solvo platform, available as a paid subscription or under a freemium model for individual developers and teams, addresses a lot of the cloud security issues that inevitably arise when infrastructure is provisioned as code by developers. It eliminates that stress by automating the creation and application of cybersecurity policies within the context of a DevOps workflows, said Shamban.

    However, a cybersecurity team can also manually edit those cybersecurity policies after an application is deployed, Shamban added.

    As DevSecOps best practices continues to evolve, it is clear the relationship between developers and cybersecurity teams needs to evolve, as well. For a long time, many cybersecurity teams viewed developers as the primary source of the problems they encountered. Getting used to the idea that those same developers are now going to solve those issues on their own requires a level of trust that will take time to build.

    Developers, for their part, are generally accepting of the idea that they should take more responsibility for security, so long as the tools provided to them are not selected by cybersecurity professionals that don’t appreciate application development workflows.

    In time, there is no doubt the cultural divide that exists between developers and cybersecurity teams will narrow. However, it’s arguable that more progress will be made, more quickly, if developers are allowed to choose their own security tools rather than accept an edict from on high mandating a specific approach. In fact, the best course of action for many IT teams is simply to offer words of encouragement to developers that elect to set an example for the rest of their colleagues.

  • Data Theorem Extends Scope of App Analyzer Portfolio

    Data Theorem Extends Scope of App Analyzer Portfolio

    Data Theorem, Inc. today added to its portfolio a Cloud Secure analyzer that promises to provide full stack visibility into applications through the client, network and cloud layers of a distributed computing environment.

    Doug Dooley, Data Theorem COO, said Cloud Secure extends an existing Analyzer Engine offering that is currently widely employed to identify vulnerabilities found in applications running on public cloud services. That enables DevOps teams to analyze application runtimes using a tool that can be integrated within a continuous integration/continuous delivery (CI/CD) platform as part of a DevSecOps workflow, Dooley noted.

    Cloud Secure now extends that capability to include the client layer for both mobile and web applications, as well as REST and GraphQL application programming interfaces (APIs) at the network layer, to provide a more comprehensive approach to attack surface management, Dooley said. That’s a crucial capability, because in modern IT environments, the single biggest attack surface is now all the APIs that need to be secured, Dooley added.

    DevOps teams can also employ multiple Cloud Hacker Toolkits, created by Data Theorem, to simulate hacks against various types of applications, including those now running on serverless computing platforms. That approach eliminates the need to rely on manual penetration tests that can’t keep up with the rate at which DevOps teams are now building and deploying applications, Dooley noted. For organizations to achieve DevSecOps, the whole security process needs to be just as automated as the rest of the DevOps workflow, he added.

    In general, Dooley said most of the results of penetration testing shared with DevOps and cybersecurity teams lack much-needed context. They may inform members of an IT team that there is a leak, for example, in an S3 bucket hosted on a cloud storage service from Amazon Web Services (AWS). However, they don’t identify what type of data is at risk. That’s critical information at a time when IT organizations need to make high-stakes decisions about where to prioritize their DevSecOps efforts.

    As developers assume more responsibility for application security, the biggest challenge organizations will face is finding security tools that can be easily integrated into application development processes that have become more extended as applications, made up of microservices, are deployed across highly distributed computing environments.

    It’s still early days as far as adoption of DevSecOps best practices are concerned, but as more tools become available, it’s becoming more feasible for organizations to make that transition from the bottom up. No developer sets out to deliberately write and deploy an insecure application. However, DevSecOps edicts issued from on high will fall on deaf ears if the developer lacks the tools required to achieve the goal. Tools that a developer embraces are going to be more widely employed than any tool that is specifically mandated by IT leaders that don’t really understand how applications inside their organization are constructed.

    Regardless of how DevSecOps is achieved, the one thing that is certain is as more applications get deployed, the probability there will be a major security incident becomes all but certain.

  • How to Mitigate Low-Code Security Risks

    How to Mitigate Low-Code Security Risks

    Gartner predicts that by the end of 2025, over 65% of development projects will use low-code builders. The field of low-code continues to expand. But what security implications does low-code introduce?

    Low-code refers to tools that enable application construction using visual programming models. Adopting drag-and-drop components instead of traditional code, no-code and low-code platforms enables non-technical folks to construct their own workflows without as much help from IT. Yet, handing power to citizen developers with less security training can be risky. Plus, low-code platforms may hold compromised propriety libraries or leverage APIs that may unknowingly expose sensitive data to the outside world. There’s also the possibility that low-code could increase shadow IT if not governed well.

    Low-code opens the door to more producers. But, does it open the backdoor, too? I recently met with Chris Wysopal, CTO and cofounder of Veracode, to discuss the growing security risk posed by low-code applications. According to Chris, hardening low-code environments involves a combination of compartmentalization, dynamic and runtime techniques, and adopting the “least privilege as possible” rule across the board. Below, we’ll expand on potential low-code risks and see what other methods Wysopal recommends organizations employ to secure the emerging low-code paradigm.

    Low-Code Security Concerns

    Verizon’s 2020 Data Breach Investigations Report (DBIR) found 43% of all breaches are connected to a vulnerability at the application layer. Thus, securing these applications, or in the case of low-code, the layer that generates them, is essential for business to function smoothly.

    When it comes to low-code, Wysopal notices a few key risk areas:

    Proprietary libraries with hidden vulnerabilities. By their nature, low-code platforms typically use a good deal of proprietary software, making securing them a bit opaque. These systems could involve a proprietary language, proprietary libraries and proprietary frameworks. If you trust a low-code platform, you place a lot of faith in the low-code vendor to have a strong security process in place.

    Some platforms do generate traditional code, which organizations can export to run on a Node.JS or Java server. Yet, this often involves a mix of code and proprietary libraries, says Wysopal. While you could run traditional static analysis on the generated code, you may miss some context.

    Lack of citizen developer security training. Citizen developers have little technical knowledge, let alone DevSecOps training. If runtime applications present vulnerabilities, expecting no-code users to mitigate them is unrealistic.

    API integrations. If low-code platforms expose an API or generate a web application via an API, the platform could be exposing sensitive data.

    Ways to Harden Low-Code Environments

    To respond to these areas, Wysopal offers some advice for securing low-code environments:

    • Perform static code analysis: Perform your own static analysis on any generated code and test for common errors. “Look at the code, and understand where it interacts with the outside,” Wysopal recommended.
    • Audit proprietary libraries: Whenever possible, Wysopal said he recommends pushing back on the vendor to question them on their application security standards and examine proprietary libraries for potential risks.
    • Verify partners: Similarly, take precautions when working with third-party partners around low-code tools. Partner tools should be carefully vetted and hold some sort of application security certification from the low-code platform.
    • Secure the API layer: Understand what APIs the application interacts with. These connections should be tested dynamically and automatically with an API scanner. Along your journey, consider these API security testing best practices.
    • Compartmentalize: Wysopal also recommends traditional isolation techniques. Consider more than just the application layer; Wysopal recommended isolating the app and running it in a virtual machine or a container.
    • Security training for citizen developers: Since citizen developers are typically not trained on appsec practices, hold security exercises to train them on fundamentals. A helpful demonstration could involve directly attacking an app to find flaws.
    • Apply the least-privilege-as-possible rule: When assigning user capabilities, whenever possible, use secure-by-default settings and allow access only to those that need it.

    By applying dynamic and runtime techniques, you may catch vulnerabilities, such as a cross-site scripting error. However, if you’re working with proprietary low-code systems, you may not be able to fix it immediately! You may have to send a request to the vendor and wait for the bug to be patched. Thankfully, most technology providers take more immediate action in response to bugs than to feature requests, Wysopal noted.

    Change the Attitude Toward Security

    On the low-code spectrum, there is the attitude that “people aren’t really doing mission-critical applications — they’re mainly doing prototyping, or back office automations,” Wysopal said. Or, since low-code applications often do not publicly expose an application, they are deemed low-risk and fall to the bottom of the security team’s inbox and list of to-dos. “We’re still in a world where people don’t secure all applications,” he said.

    However, these attitudes are a bit short-sighted, since “applications aren’t islands,” Wysopal said. Even if applications are intended for internal use only, phishing attempts could expose credentials and gain access to the network. Here, attackers could leverage sensitive resources or steal infrastructure for compute power.

    Thus, all low-code users should be aware of potential threats and change habits to address these risks accordingly. However, the onus is also on low-code vendors to sufficiently arm their systems. Having a vulnerability disclosure, bounty program and an easy means to accept bug reports from white hat security researchers will be necessary to continually patch issues.

    No-Code ≠ No-Bug

    Low-code continues to permeate more and more digital operations, opening up novel potential for citizen developers. While the low-code movement promises impressive returns, it also brings potential risk.

    To mitigate these concerns, we must level up our security understanding and evolve our approaches, Wysopal said. “Any application can have flaws and security bugs in them.” Just because you’re not writing a function in C and are relying on a visual programming model doesn’t mean you’re not introducing flaws.

    Disseminating the real risk of resources and dependencies, along with helpful consumer-facing documentation, will set the superior low-code platforms apart from the rest. Otherwise, putting faith in proprietary libraries will be a tough pill to swallow.

  • Managing Business Risk in a DevOps Context

    Managing Business Risk in a DevOps Context

    We hear a lot in the industry about the importance of automation in DevOps to enable speed. However, there is another element that is often missing in the discussion – risk, compliance and security. Traditionally we have a zero-sum approach, where we need to either go fast or be safe and secure. It’s one or the other. Or, maybe not! There is an 80%-80% middle ground to consider. Balanced development automation is a natural evolution of DevOps; it is not just about the technical side anymore, but also includes the risk and the compliance side, as well.

    Aligning Executives

    How do we get business executives and risk executives, at the strategy level, to align on this idea of balanced development automation? First, it is important to realize that what represents a risk for businesspeople is different than the risk that’s perceived by the development group.

    For example, let’s say there is an urgent requirement for some sort of additional business functionality in response to competitive action, or even in response to a pandemic. From a business standpoint, risk might represent a failure to deliver an effective solution within the particular timeframe required. From an IT standpoint, concerns about risk are likely going to be different from the business risk.

    That being said, it’s a futile exercise to convince business management to think in terms of perceived IT risk as opposed to business risk. IT must be able to translate the risks of their development work into business risk, or management may not see the potential impact of that risk. And so, pressure remains to “Get this thing done as quickly as possible!”

    Even at the executive levels, there is a discrepancy in identifying what risk really is. That is true at similar management levels at different organizations, even within the same industry. Let’s look, for example, at the whole issue of security and how much effort we should be paying to validate the security of a system that we’re putting in place, or that we already have in place. If an organization has experienced a breach, they are much more likely to have a management team that is concerned about security. In a different organization that has not seen any security breaches, they may not be paying as much attention or making the appropriate investments to make sure systems are secure.

    Aligning DevOps and Security

    We also need DevOps engineers and security engineers to align at the tactical level. So how can these teams, that are typically at the program or project levels, integrate and think about balancing development speed with risk and security? Operational teams are very important in achieving balanced development automation. If we look at the risks from the perspective of the development team, it doesn’t matter what technology you’re using to develop an application, or even if you’re implementing someone else’s application.

    From an IT standpoint, one of the most likely risks is failure to deliver functionality of the particular project that you’re doing. That is an example of delivery risk, which senior management is very concerned about. The way that tends to manifest is in delayed delivery or allowing the business to change their mind during the particular project. The risk of not delivering the functionality that’s required is increased. The process is just going to crack simply because the project has not been managed effectively, requirements were not stabilized or adequate testing was not done.

    That is an extremely high risk that development groups need to be aware of. A development group needs to apply some type of balanced methodology and minimize the likelihood of a gap between the expected outcome of the project and the actual outcome.

    Demand for Balanced Development Automation

    Today’s business context demands both speed and some awareness of risk from development teams. This will only be achieved through alignment at the executive level and at the tactical level. Focusing on areas of business risk are essential to achieving this alignment.