devopsy.kinsta.cloud

Tag: code security

  • OutSystems Embraces Generative AI to Speed App Dev

    OutSystems Embraces Generative AI to Speed App Dev

    OutSystems, via a Project Morpheus initiative, intends to leverage generative artificial intelligence (AI) technologies to make it possible to automatically generate an application that developers will then use low-code tools to customize for specific use cases.

    In the meantime, the company is extending an existing alliance with Microsoft to provide a connector that integrates its namesake low-code platform with instances of ChatGPT. These instances are made available via Microsoft’s Azure OpenAI cloud service to make it possible to build a low-code application in a matter of minutes.

    Rodrigo Coutinho, director of data science for OutSystems, said that as generative AI continues to evolve, it will become possible for developers to use a natural language interface to create an application. However, there will also be plenty of instances where end users still prefer to access applications via a graphical user interface that developers build using low-code platforms, he noted.

    An application editor will also provide ongoing suggestions for everything from how the user interface is designed to the way data is managed.

    Developers will also be able to verify how code functions using the OutSystems visual language. In addition, The OutSystem compiler will be able to deterministically detect threats and code patterns produced by generative AI platforms that will include Google, Amazon and others alongside Microsoft.

    Ultimately, citizen and junior developers will be able to build sophisticated applications that previously would have required the skills of a professional developer, noted Coutinho.

    It’s not clear how much developers will embrace a low-code platform to build software. However, the one thing that is certain is the whole process of defining requirements before an application can be built will soon become obsolete as the building of an application becomes more iterative and involves developers working alongside subject matter experts, added Coutinho.

    It may awhile before that vision of application development is realized, but the pace at which applications are built and deployed is clearly about to accelerate. The impact of all that code will naturally vary, but it’s already apparent that the cost of building many applications may soon drop to almost zero. Developers will soon be spending more time on making sure workflows are logical than writing actual code, noted Coutinho.

    In addition to relying more on AI to build software, organizations should also rely more on AI to deploy it at unprecedented levels of scale. The days when application development projects were measured in months, sometimes years, is coming to an end. AI platforms will enable organizations to experiment at will because the time and effort required to build and deploy a new iteration of an application will be virtually nil.

    Of course, no one can predict what impact all that code will have on society as we know it. But the only limit going forward may soon be what our collective imaginations can conceive than the level of developer expertise that can be marshalled at any given time.

  • A DevOps Guide to the Language of DevSecOps

    Security is increasingly important for DevOps due to the growing complexity of applications and the accelerated pace of development. As organizations adopt DevOps practices, they face new challenges in securing applications and infrastructure:

    • Increased complexity and automated processes: With automation at the core of DevOps, processes and applications are more intricate. This can introduce vulnerabilities if not carefully managed and secured, as they often involve multiple systems and components that need to be protected.
    • Reliance on code repositories: DevOps teams depend heavily on code repositories for version control and collaboration. However, these repositories can be targets for attackers seeking to inject malicious code or steal sensitive information, making it crucial to secure access and maintain good security practices.
    • Larger attack surface: The DevOps pipeline consists of numerous tools and components, including source code management, build systems, testing frameworks and deployment tools. Each of these elements presents potential attack surfaces and needs to be secured to protect the overall application.
    • High-velocity development: The rapid pace of development in a DevOps environment can sometimes lead to security being overlooked or deprioritized. As new features are pushed out quickly, there may be less time for thorough security reviews.
    • Tooling limitations: While many DevOps tools come with built-in security features, these may not be sufficient to protect against all threats. Relying solely on these features could create a false sense of security, leaving organizations exposed to potential attacks.

    What is DevSecOps?

    DevSecOps enables teams to shift security left and integrate it continuously across the entire SDLC rather than as an afterthought. It is a cultural shift even for DevOps teams, as it requires all members to adopt a security mindset that ensures software is not only released fast and at the highest possible quality but also includes all security measures and checks from the design phase.

    It typically involves adopting secure coding practices and implementing application security testing tools that help design, test, verify, release, and update secure software in a secure manner. It requires ensuring that not only the software itself is secure, but also the development environment and the entire supply chain is secure. As a result, DevSecOps rely on a high level of automation tools to reduce manual work to a minimum.

    DevOps Guide to Security Acronyms

    All DevOps pros need to become familiar with key security concepts. Here are a few concepts that will help you communicate better with security teams in your organization and one day become a DevSecOps geek yourself.

    1. SBOM—Software Bill of Materials

    A software bill of materials (SBOM) comprises all components and software dependencies in the application’s build and delivery. It provides visibility into all the different components and licensing included in a piece of software to help discover potential vulnerabilities and licensing risks.

    2. DAST – Dynamic Application Security Testing

    DAST involves analyzing applications or services while they are running to identify security vulnerabilities. This technique typically simulates attacks to learn how a malicious actor might exploit the user or application interface. Teams use DAST tools to detect complex vulnerabilities caused by specific functionality that a static analysis tool cannot find when analyzing the source code.

    3. SCA – Software Composition Analysis

    SCA tools identify security vulnerabilities in third-party components and dependencies. Teams can integrate SCA to run across the entire development pipeline to build an open source dependency tree for the application and map these components against a database of known vulnerabilities. The tool generates reports on vulnerable open source components found in the application that require fixes or patches.

    4. SAST – Static Application Security Testing

    SAST tools analyze the source code of applications, services, and microservices, trying to identify potential vulnerabilities caused due to insecure coding practices. Teams can integrate SAST tools into their continuous pipeline, setting them up to automatically search the source code for coding patterns and insecure objects or functions that can result in security vulnerabilities. SAST is commonly used to identify vulnerabilities during the coding phase or when pushing code to a testing environment.

    5. IAST—Interactive Application Security Testing

    IAST involves analyzing the source code for vulnerabilities while the application is running. The main advantage of IAST is that this method reports vulnerabilities in real-time and does not add additional time to the CI/CD pipeline. It works from within the application, distinguishing it from both SAST and DAST techniques that work externally. IAST does not scan the entire codebase. Instead, it checks only the aspect exercised during the functional test.

    6. RASP—Runtime Application Self-Protection

    RASP is a defensive technique built into the tested application to detect and respond to attacks as they occur. It is typically implemented using third-party tools embedded within the application to monitor incoming requests and the application’s behavior, such as packages, plug-ins or libraries. These components inspect requests and the application’s behavior to block and protect against threats.

    7. OWASP—Open Web Application Security Project

    OWASP is a nonprofit devoted to helping improve software security by offering free resources and tools. This organization consists of a large community of volunteers who help propose, build and manage projects and educational materials that support the wider software development and security community.

    8. XDR—Extended Detection and Response

    XDR solutions collect and correlate deep activity data and detections across various security layers, including endpoints, emails, servers, networks, and cloud workloads, performing automated analysis to help detect threats faster. Teams can use this information to take quicker action during investigations. The main advantage of XDR solutions is that they help break down the security silos that allow stealthy threats to evade detection. 

    9. XSS—Cross-Site Scripting

    XSS is a security vulnerability. It plagues so many web applications that it has yet to be removed from the OWASP Top 10 web vulnerabilities list since it was first included in the 2003 version. XSS vulnerabilities enable threat actors to execute malicious script code in one or multiple users’ browsers. Actors often use XSS to gather sensitive information, such as user session details and personal data. 

    10. SQLi—SQL Injection

    SQLi is a code injection technique that enables threat actors to attack applications. It typically occurs when applications require user input, such as usernames, but receive a malicious SQL statement instead. To launch this attack, actors must locate vulnerable user inputs in the web application, create input content and send it. If the database executes the malicious SQL command, the attacker gains access to the database.

    11. CSRF—Cross-Site Request Forgery

    CSRF is a common web application attack that exploits the trust between a user and an application to conduct various malicious actions. Threat actors use CSRF to hijack an authenticated session between a user’s browser and an application. Once actors have access to the session, they can use it to execute functionality on that application.

    12. SAML—Security Assertion Markup Language

    SAML is a standard used to securely share information about identities, authentication, and authorization between various systems. It is typically implemented with the Extensible Markup Language (XML) standard for data sharing and often provides an open framework to implement a federated identity system like single sign-on (SSO). 

    Conclusion

    In today’s chaotic cyber landscape, DevOps teams cannot solely prioritize the fast release of high-quality software. To ensure their software, infrastructure and development environment are protected, DevOps teams must integrate security into the entire SDLC. This endeavor requires adopting a security mindset and utilizing tools that help create an efficient and secure pipeline. 

    The acronyms discussed in this article include essential security aspects DevOps teams should get familiar with, such as the OWASP organization that provides important guidance on building secure software, tools that help shift security left and common web vulnerabilities. However, teams should branch beyond these practices and tools to create a comprehensive security policy that covers their unique needs and requirement.

    Image Source 

  • A Seven Point Checklist for Getting SAST Right

    A Seven Point Checklist for Getting SAST Right

    With so many physical products—from automobiles to airplanes and medical devices to industrial control systems—now being driven by software, product security has become a top-level concern for manufacturers. Software flaws can not only affect security by introducing vulnerabilities that can be exploited by attackers but also impact safety by compromising a product’s functional operation.

    In addition, product security has significant financial implications. For example, fixing a vulnerability in development costs 10 times less than in testing and 100 times less than fixing it in production. This explains why static application security testing (SAST) has become a cornerstone of product security and the engine for implementing code analysis at the earliest stages of development, commonly known as shift left security.

    Unlike other forms of application security testing (AST), SAST scans 100% of the code, including configuration files, not just the code that is executed at runtime. SAST can also provide additional benefits, such as quality and architectural testing. Software quality and security are inextricably linked since poorly written software typically is insecure software.

    With the stakes so high, getting SAST right is the tipping point for any product security program. To evaluate SAST tools, consider the following checklist to make sure they align with your business requirements:

    1. Deep Language Support: C/C++, Java, C#, etc.

    Languages are often selected based on the programmatic requirements of the software producer, the needs of the consumer and the hardware associated with the product. For example, developing software for safety-critical applications like aerospace requires different capabilities than languages used to build web applications.

    2. Compiler and Embedded OS Platform Compatibility

    Compilers used for embedded software development implement unique flags for configuration, such as performance optimizations, code size, error checking and the diagnostic information emitted. Since embedded OS platforms typically include compiler and debugging tools plus the various OS files and configuration options, make sure the SAST tool can integrate with the development environment used.

    3. Actionable Alerts

    For the DevOps team to embrace security, embedding security in the software factory life cycle cannot slow down development velocity or hinder developers’ ability to meet software release timelines. False positives redirect developer attention away from writing software to investigating potential defects. Too many false positives result in developers losing faith in true positives and paying less attention to security alerts of real substance.

    4. Built-In DevOps Integration

    The software development life cycle employs an extensive toolset that provides automation to help developers get products to the production stage faster—not unlike a manufacturing plant or factory. Make sure the SAST tool supports and integrates with distinct tool categories including collaboration and management, source control and repositories, IDEs, compilers, orchestration and automation and business intelligence.

    5. Flexible Deployment

    Depending on the organization and industry, SAST may need to support a variety of deployment options, including on-premises, cloud, hybrid, etc. For example, air-gapped deployments are often required in security-sensitive environments where the data protection uncertainty associated with multitenant public clouds is unacceptable. Meanwhile, cloud-based SAST can provide benefits like scalability and elasticity and reduce infrastructure capital investments.

    6. Developer-friendly UI

    Shift left security is accomplished by integrating security warnings into the integrated development environment (IDE) used by engineers. A SAST tool that works within existing IDEs can reduce the number of errors presented to testers, which subsequently reduces the volume of kickbacks to engineering and leads to faster time-to-market.

    7. Standards

    Many organizations use—and some must comply with—standards for software coding best practices such as SEI CERT, MISRA, etc., which provide a framework for improving the safety, reliability and security of software systems. In addition, a company may need to satisfy functional safety standards such ISE 61508, as well as derivative industry specific standards including IEC 62304 (Medical), ISO 26262 (Automotive),  DO-178C (Avionics) and IEC 62434 (Security). A SAST tool should provide integration with key standards that govern an organization’s products and, where appropriate, be certified for them.

    Using these guidelines for evaluating SAST tools will help ensure that the product you select meets your organization’s business, technology, safety and security requirements.

  • Google Allies With GitHub to Secure Software Supply Chains

    Google Allies With GitHub to Secure Software Supply Chains

    Google today revealed it has been working with GitHub to create a forgery-proof method for signing source code as part of an ongoing effort to better secure software supply chains.

    Bob Callaway, technology lead for open source software supply chain security at Google, said a prototype of this method, written in the Go programming language, generates non-forgeable provenance using GitHub Actions workflows for isolation and code signing tools for authenticity provided by Sigstore. Projects that make use of GitHub runners to run jobs can now achieve the third level of security as defined by the supply chain levels for software artifacts (SLSA) framework to assure software artifacts are authentic and trustworthy, he said.

    The reusable workflow also protects against possible interference from maintainers who could otherwise try to define the workflow in a way that interferes with the builder. The only way to interact with a reusable workflow is through the input parameters it exposes to the calling workflow, which prevents maintainers from altering information via variables, steps, services and defaults.

    The goal is not only to ensure the provenance of individual software artifacts but also make it possible to identify which build system was employed to create that artifact, said Callaway. In addition to working with GitHub, Callaway added that Google expects to apply this method to securing other build systems that organizations used to construct applications.

    Overall, Callaway said, Google is also working toward embedding security functions with DevOps platforms to ensure the integrity of software supply chains, in addition to educating developers on how to build more secure software.

    To protect against the possibility of one job tampering with artifacts used by another job, Google’s method creates a trusted channel. Job outputs send hashes that are then used to verify the binary received via the untrusted artifact registry. The OpenID Connect (OIDC) protocol, which GitHub just opted to support, is then used to prove the identity of the workflow to an external service, such as Sigstore, by attaching a unique JSON web token (JWT) to each runner. The token contains verifiable information about workflow identity such as the caller repository, commit hash, trigger and the current workflow path and reference.

    That makes it possible for the workflow to prove its identity to the  Fulcio root certificate authority provided by Sigstore. Fulcio signs a short-lived certificate attesting to an ephemeral signing key generated in the runner. A record of that signing is kept in Sigstore’s transparency log Rekor. Users can then rely on the signing certificates to verify provenance in a way that is authenticated and non-forgeable. That approach means maintainers don’t need to manage or distribute cryptographic keys for signing, which until now have made it challenging to manage code signing at scale, Callaway noted.

    In the wake of a series of high-profile security breaches involving open source software, Google and others have significantly increased the resources being applied to securing both open source and proprietary software within the context of a set of DevSecOps best practices. It may be a while before the benefits of that effort are pervasively employed by developers, but it’s clear that substantial progress is being made involving everything from the tools developers use to the build systems managed by DevOps teams.

  • Securely Streamline Code Signing for DevOps and DevSecOps

    Securely Streamline Code Signing for DevOps and DevSecOps

    Introducing code-signing provides security within the application, but teams should take care to understand and implement the process effectively

    Digital certificate management, with hundreds or thousands of certificates required to support IT infrastructure, can easily lead to degradation of application integrity and unnecessary risk to the business. The cumbersome nature of siloed teams manually managing digital certificates often results in the bypassing of PKI standards mandated by their organization.

    Based on the complexity of their pipeline, DevOps and DevSecOps teams may issue certificates signed by an untrusted source and stored insecurely to speed up the build and deployment stages of CI/CD workflows to avoid a lengthy certificate request process, which could take weeks or even months. Using this manual, insecure cryptographic practice to sign and deploy code exposes organizations to a high level of avoidable risk.

    Code signing, and the certificates used in that process, should be centralized and automated using cryptographic hardware. Here we will walk through the process of hardened code signing and how to streamline its management in DevOps and DevSecOps pipelines.

    Hardened Code Signing in 4 Steps

    1. Unsigned code ready for distribution. Time to generate public-private key pair

    We start with an unsigned executable that is ready for distribution. To securely sign the code, the code publisher needs to generate a public-private key pair. This is required by most runtime architectures, including Windows, Java and others. The most secure way to generate code-signing keys is by using a FIPS 140-2 Level 3 validated hardware security module (HSM).

    1. Submit public key and Certificate Signing Request (CSR) to an issuing certificate authority (CA)

    With the key pair generated in step No. 1, the CSR is generated and submitted to an issuing CA. The CSR contains information that identifies the publisher and signature algorithm, as well as the digital signature. This information is used by the issuing CA to issue the code signing certificate.

    In some situations, such as with internet of things (IoT) device manufacturing, the organization may decide to act as its own Issuing CA.

    1. Identification of publisher and authentication of CSR

    The Issuing CA verifies the code publisher’s identity then authenticates the CSR, ensuring the publisher has digitally signed it. If both identification and authentication are successful, the Issuing CA packages the publisher’s identity with the public key then signs the package, creating the code-signing certificate.

    1. Ready to sign. Determine the level of security

    Now that the code-signing certificate is ready for use, any executable can be signed and deployed unless further code testing or QA needs to occur. Enterprises, particularly fast-moving ones, often find themselves storing their code-signing keys on the code publisher’s local machine or server, an insecure method that can result in significant problems. Storing the keys on a local machine or server presents major security risks. The local machine could become compromised/stolen along with the code-signing keys, or a disgruntled employee could maliciously sign and deploy unauthorized code, which could go unnoticed for a while.

    It is best to import and store the code-signing certificate in a key management server (KMS), which stores the certificate behind a FIPS 140-2 Level tamper-resistant physical boundary. In addition to hardened storage, a KMS with proper cryptographic features and functionality can be utilized to help automate the entire code-signing and certificate management life cycle. A KMS allows DevOps and DevSecOps teams to seamlessly meet best practices while removing the manual workflow bottlenecks and natively integrating with CI/CD systems. Less time generating and managing digital certificates results in faster code deployments and an increase in team output.

    Streamline Continuous Integration

    There is tremendous value in using an HSM for secure key generation and certificate storage. Additionally, DevOps and DevSecOps teams can drastically reduce the manual labor required with continuous integration code builds. For builds requiring a defined and trackable workflow for signing, code signing with CI/CD integration can offer significant benefits.

    This workflow typically consists of a CI/CD system that is managing the build and signing request process, a centralized and secure key management server to manage all code-signing keys and perform the signing process, and an approval entity to govern the process by which code is signed in an authorized manner.

    When deploying a system like this, backed by a FIPS 140-2 Level 3-validated HSM, organizations can also introduce automation into the process. This means that instead of code signing being a manually driven step that introduces room for human error, it is natively incorporated in the code development and release workflow.

    Integration With Code-Signing Technologies

    KMS and HSM cryptographic devices that provide hardened key storage commonly integrate with popular code-signing technologies that conduct various tasks such as validating publisher identity and ensuring code integrity. For instance, organizations using SignTool.exe with Microsoft Authenticode can directly integrate with a KMS with full certificate management functionality. Other integrations and use cases include Java Jar Signer, RPM (Red Hat), Docker, and various IoT implementations. Beyond that, innovative organizations are looking at systems that can deploy more advanced code-signing workflows outside of the standard OS and runtime SDKs, to integrate more tightly with CI/CD systems.

    Integrating HSMs into DevOps and DevSecOps pipelines simultaneously improves workflow efficiency and supports other cryptographic operations across the organization.

  • Accurics Makes Infrastructure as Code More Secure

    Accurics Makes Infrastructure as Code More Secure

    Fresh off raising $5 million in funding, Accurics today launched a platform that analyzes the code employed to manage infrastructure as code for vulnerabilities as well as indicators of drift to create a threat model for cloud application workloads and then, if necessary, automatically roll back cloud settings to their last known approved state.

    Accurics CEO Sachin Aggarwal said rather than simply focusing on cloud infrastructure, the startup company’s platform analyzes vulnerability feeds, identity access management (IAM) privileges and other data to detect potential cloud security issues. That analysis can then be shared with third-party security tools to automate remediation, he said.

    Once the model is constructed, Accurics then monitors the application workload for changes that introduce risks and generates a topology for each workload in real-time to identify any potential indicators of drift away from the initial deployment settings. If the drift is due to a legitimate change, the code can be updated. If it introduces risks, IT teams can roll their code back to the last known secure posture using a “time machine” capability that Accurics has baked into its platform, he said.

    AccuricsThe Accurics platform takes a different approach to cybersecurity—rather than focusing solely on application programming interfaces (APIs) exposed by cloud infrastructure providers, it analyzes everything from the Terraform code used to programmatically install workloads to the container and serverless computing frameworks employed. In the future, Aggarwal said Accurics plans to add integrations with other infrastructure commonly employed in cloud environments, including Jenkins, Bitbucket and GitLab continuous integration/continuous delivery (CI/CD) platforms.

    That analysis surfaces violations of common compliance and cybersecurity practices based on Security Operation Center (SOC) 2, General Data Protection Rule (GDPR), Payment Card Industry (PCI), Healthcare Information Portability and Accountability (HIPAA), International Organization of Standardization (ISO), Center for Internet Security (CIS) Benchmark, Amazon Web Services (AWS) Best Practices and the AWS well-architected framework.

    Aggarwal said Accurics advances DevSecOps by making it possible for organizations to continuously assess changes within their cloud application environments. Most of the issues involving cloud security today can be traced back to errors made while using tools to programmatically provision cloud infrastructure. The Accurics platform helps developers and cybersecurity teams to collaboratively discover those issues, he noted, adding the overarching goal is to enable both teams to reduce risks by eliminating the most common mistakes that are made in cloud computing environments.

    As the relationship between DevOps and cybersecurity teams continues to evolve, it’s become apparent the first issue most organizations need to address when it comes to cloud security is visibility. Most IT teams are concerned about cloud security not because the platforms are less secure than on-premises infrastructure. In general, cloud infrastructure is more secure. However, because of a lack of visibility, it’s not as easy for cybersecurity teams to discover when misconfigurations create a known vulnerability. If that issue gets resolved, much of the resistance to cloud computing generated by security concerns will fade away.

  • Securing Third-Party and Open Source Code Components: A Primer

    Securing Third-Party and Open Source Code Components: A Primer

    The increasing popularity of open source code continues to be a boon for developers across the industry, allowing them to increase efficiency and streamline delivery. But there are security risks to be considered when leveraging open source and commercial code components, as each carries with it a significant risk of becoming the enemy within, creating a vulnerability in the program it helps build.

    Sacrificing Security for Ease of Use

    While the many benefits of open source have been well-touted, the sheer prevalence of code components (open source and commercial) across industries is underestimated. CA Veracode recently found that 83 percent of developers use code components to build web applications, with the average number of components per application at a whopping 73.

    Considering the fact that the vast majority of developers build applications with code components, the number of those familiar with the risks of doing so is startlingly low. A mere 52 percent of companies reported they provide security fixes to components when new security vulnerabilities are discovered. Despite an average of 71 vulnerabilities per application introduced through the use of third-party components, only 23 percent reported testing for vulnerabilities in components at every release.

    Furthermore, only 43 percent of developers reported being aware of the industry-accepted OWASP recommendations for preventing the use of components with known vulnerabilities.

    Where Does Responsibility Lie?

    One clear issue in this software development practice is that responsibility for securing code seems to fall on everyone—and, sometimes, no one. Forty-four percent of respondents claimed that developers are responsible for the continued security of code components, while 31 percent reported that they expect security to handle this task.

    This lack of preparedness and miscommunication leaves the door wide open for bad actors to swoop in and take advantage of vulnerabilities that could so easily be fixed.

    How, then, can teams ensure the security of applications built with code components? The solution lies in three key steps:

    • Start with education: Software development teams must have the tools and training necessary to ensure the code they write is secure. Educating developers on the risks associated with open source and commercial code components is a start, but prioritizing security training and ongoing education is the key to long-term success. Tapping the security team to lead trainings for their developer colleagues is a good way to embrace peer knowledge-sharing and break down silos between the two teams.
    • Introduce clear processes: To alleviate miscommunication and confusion, organizations must implement clear processes for secure software development. Knowing what an application is built of is the first step, as teams can’t secure what they don’t understand. This may seem obvious, but CA Veracode found that only half (53 percent) of organizations keep an inventory of components. Code components should be thoroughly vetted before being worked into an application and then should be added to a working inventory. Managers should be sure each part of the maintenance process has a clear owner on the team so responsibility is always clear. Consistent testing and patching are also best practices when it comes to security.
    • Drive innovation with DevSecOps: All of this comes back to integrating security into the entire software development life cycle (SDLC) and implementing DevSecOps, because a team that operates in silos will never be able to push out secure code. The development, operations and security teams each provide their own unique and critical contribution to the software development process, and combining forces will result in the best possible product.

    While taking the time to secure applications from the perils of code components may slow down development in the short term, safeguarding your organization and its software assets is invaluable in the long term.

    — Pete Chestna