devopsy.kinsta.cloud

Tag: DecSecOps

  • Three Ways to Speed up SAST

    Three Ways to Speed up SAST

    In modern, continuous software development life cycle (SDLC) processes, when code is written and before it’s committed to the repository, it’s run through testing, which may include unit testing, regression testing or static application security testing (SAST). The benefit of SAST for DevSecOps is the real-time feedback it provides developers as they create and make changes to the source code before they submit it. The amount of time that’s acceptable in this kind of workflow is 15 minutes to 30 minutes maximum, with some allowance for how big the change is. Fast feedback means quicker turnaround and more progress on features. The business value lies in those features. Testing makes sure they work.

    Depth Versus Breadth

    Checkers used by SAST are not all created equal, at least in terms of the computation power needed. The time for analysis is directly related to the complexity of the checkers used to detect certain types of vulnerabilities. Typically, coding standard enforcement rules are easier to compute versus complex tainted data analysis used to detect command or SQL injections, for example. Therefore, there is a trade-off to be made in the types of bugs and vulnerabilities being detected. When developers are coding, it makes sense to optimize the compute time for SAST to reduce any delays. During software builds, more time and compute power is available so depth and breadth can be increased to catch complex vulnerabilities.

    Compute Power

    SAST analysis time scales well with compute power. The availability of more computing resources such as CPU and memory, can impact the time of analysis. Bigger is better in this case and investing in additional hardware for SAST can pay off in terms of productivity.

    Codebase Size

    SAST analysis time is also dependent on the amount of source code analyzed. Depending on the application, the code base is a determining factor in terms of what depth and breadth of analysis is optimal.

    There is some correlation between small code base size and strict requirements for SAST such as in safety-critical software. It’s expensive to build and test safety-critical code, but code size is typically smaller than in other types of applications. However, these products need to conform to industrial coding standards and thus require rigorous levels of testing and analysis to detect a wide variety of defects.

    Larger and extremely large code bases require a trade-off in terms of depth and breadth of analysis. Prioritizing the types of defects and vulnerabilities to concentrate on is critical.

    Speeding up SAST means reducing the amount of work. The most intensive operation is a full analysis of the entire source code base. Just as full compilation from scratch takes a long time, the same is true of SAST analysis.

    To accelerate SAST processing times, follow the same three techniques used to avoid compilation in large C/C++ projects: incremental analysis, component analysis and developer analysis.

    1. Incremental Analysis

    Incremental builds are a major factor in reducing developer build times for C and C++ projects. Small changes don’t require the entire code base to be recompiled. It’s impractical and unnecessary. When a developer modifies something, only what’s needed to be recompiled gets recompiled automatically, and the build infrastructure handles it.

    SAST works in a similar manner. As source code is being compiled, SAST parses the same source code and creates a program model. The second phase is analyzing that program model against the configured checkers and generating warnings. The warnings typically go into a database for later analysis.

    During the build of the software, SAST is run in parallel. Although similar to a compiler in operation, SAST must do more work than the compiler and takes longer to finish and provide results. The amount of code needed to recompile for each change directly impacts analysis time.

    Meanwhile, SAST of an incremental build requires a lot more work than just analyzing the changes. SAST uses abstract execution of code flow through multiple different compilation units. So even though a single file is modified, the calls it makes to other files need to be analyzed as well. The incremental analysis doesn’t increase the build and parse workload, but the analysis scope will be a lot bigger than expected. So, whenever you do an incremental build, SAST will need to reanalyze the dependencies, changes and related bits and pieces around those changed units.

    Nevertheless, it remains a good option for reducing SAST analysis times.

    2. Component Analysis

    If the software being developed has a loosely coupled, component-based architecture with well-defined interfaces, it’s possible to isolate both the testing and the SAST analysis to the component where changes were made. Just as this type of architecture simplifies many aspects of development, it pays off with SAST as well. It’s possible to analyze the component in isolation and get good results.

    3. Developer Analysis

    To further reduce SAST workload, start the first build without SAST, which removes the burden of the extra computation needed. Since subsequent builds are a lot smaller and build speed is much faster.

    However, there is an increase in false negatives due to the smaller scope of analysis since only files that changed are analyzed. This smaller scope means that all possible dependencies are outside the program model and are not considered in the analysis. However, this rapid analysis works well with coding standard enforcement, for example.

    Developer SAST

    Where to Start?

    Begin with a full build and analysis. This sets a baseline for detected bugs and vulnerabilities and establishes a performance target for reducing build time. This step will determine the exact number of lines of code, how long the analysis takes and its impact on build server load. These metrics should drive the analysis optimization effort.

    Given the options, the first step should be a component-based analysis. If this works well, it’s still possible to further reduce analysis with incremental and developer analysis within components. This approach can be integrated into typical developer workflows.

    When creating a developer branch for implementing changes, quick developer local analysis will catch local errors. These tend to be the largest set since they represent the largest part of the code changes. When enforcing coding standards, this is the point where violations are identified. A full analysis is recommended on a merge request to detect remaining defects related to cross-component-boundary behavior.

    Speed up SAST

    To speed up SAST consider using these techniques at the appropriate development stage to reduce time to complete, while still producing excellent results. Keep in mind that:
    ● Complete analysis yields the best and most precise results,
    ● Incremental analysis only analyzes recompiled code that has been modified,
    ● Component analysis works well in software that follows a well-defined component architecture and
    ● Developer (local) analysis provides a good compromise of precision and analysis time.

  • The Missing Link in DevOps Cloud Security

    The Missing Link in DevOps Cloud Security

    We’ve all seen the data from the latest Verizon Data Breach Incident Report that shows half of security breaches stem from credential abuse. It’s clear that credential compromise is an epidemic in cybersecurity and can be largely avoided with multifactor authentication and least-privilege policies. Misused credentials have shot up by almost 30% over the last five years, according to Verizon. Engineers and developers are not immune to this plague; they may be even more attractive to attackers because admin privileges allow access that reaches far beyond that of the everyday user. In fact, they are often granted always-on access when, in reality, they only need brief, intermittent access to get their job done. According to Gartner, privileged access carries significant risk. Even with PAM tools in place, the residual risk posed by users with standing privileges remains high. They recommend identity and access management (IAM) leaders implement just-in-time (JIT) strategies and, eventually, reach a posture of zero standing privileges.

    Giving engineers right-sized permissions with only the privileges they need to carry out specific tasks is especially important when these credentials are used to stand up or make changes to production resources.

    Just in Time for Developers

    JIT inventory management has been standard in many industries for decades. Especially in manufacturing, where factories can’t afford to have supplies sitting in the warehouse unused, assembly lines lying idle or have production at a standstill while waiting for parts. In information security, JIT management grants users privileged access for only the amount of time needed for a user to complete a task. This helps minimize the attack surface and avoid the risk caused by long-standing unrevoked privileges.

    In today’s agile environments, development engineers need to move and fix things fast. For example, cloud infrastructure environments are usually set up and maintained by DevOps and development teams via continuous integration/continuous delivery (CI/CD) pipelines. But developers sometimes also need direct, highly privileged access to production environments for more specific tasks.

    While static privileges that allow developers to perform day-to-day tasks are typically provided through the network’s IAM system, organizations often lack the ability to grant and revoke privileges dynamically for cloud environments. That’s because traditional on-premises privileged access management (PAM) and identity governance and administration (IGA) solutions don’t support cloud-native—and increasingly multi-cloud—infrastructures.

    Developers will always need quick, highly privileged access to sensitive cloud environments for activities such as debugging or manual deployment of a service. But those wide-ranging entitlements don’t need to be permanent and can introduce a significant risk if they’re not revoked once the job is done.

    This has left organizations resorting to risky, overprivileged practices. Inactive accounts are the source of many cybersecurity headaches. In fact, that is how cybercriminals breached the network of Colonial Pipeline in last year’s ransomware attack that shut off gas supplies. Overprivileged accounts are another big headache, which was a big factor in the now-famous SolarWinds attack.

    JIT Access

    This is where JIT access comes into play, and can enforce highly granular entitlement management for privileged access in the cloud. Gartner has become an advocate of JIT since it enables a number of security best practices. They recently advised security leaders to implement “a process for quick and easy requesting and granting of additional privileges with minimal disruption to an individual’s workflow.”

    One of the biggest challenges to implementing JIT privilege management is provisioning. Security staff is overtaxed, especially as the adoption of multi-cloud environments keeps adding complexity to their work. Provisioning individual, temporary permissions for each task becomes onerous when there is so much more to oversee.

    JIT privilege management for the cloud has to meet developers’ need for speed, self-sufficiency and transparency. One approach is to use a self-service portal that accepts requests for elevated privileges, manages the approval process, grants authorized permissions and automatically revokes them when they expire.

    A JIT Framework for Developer Security

    This framework provides security and productivity benefits.

    First, it minimizes the cloud attack surface by enforcing temporary and granular least-privilege policies. This prevents attackers that have compromised a user’s credentials from using excessive permissions to access sensitive resources and exfiltrate data.

    Second, it saves engineering teams time and effort by enabling them to quickly submit a request, notify approvers and gain temporary access. This automated workflow eliminates delays and allows DevOps staff to get their work done more rapidly and securely.

    Finally, monitoring user activity during elevated privilege sessions makes it possible to generate reports for all JIT access requests and authorizations to enforce security policies. It also creates an audit trail for forensic analysis in a security incident.

    When implementing a JIT framework for cloud privilege management, consider the following best practices:

    Look for tools that offer developers a seamless experience through a self-service portal. This saves everyone time by automating the submission, processing, approval and logging of access requests.

    Define owners for each step of JIT approvals including who manages eligibility, who approves the scope of access and who reviews requests.

    For low-risk access requests or those involving non-production environments, use policies that eliminate the need for human intervention. The system should be able to log requests, assess the stated reason for the escalated privileges and the timeframe and respond rapidly.

    Reducing the Attack Surface With JIT

    Giving DevOps staff unfettered access to sensitive resources, especially in production environments, for extended periods of time violates basic security hygiene best practices. JIT privilege management enables organizations to keep engineering activities on track and on time without incurring excessive risk. By reducing the attack surface associated with DevOps identities, even if a user’s credentials are compromised, a hacker will not have the keys to the proverbial kingdom. This will limit the blast radius of an attack.

    The challenge companies face is extending traditional privilege management capabilities to cloud environments. Fortunately, new cloud-native advances in IAM and PAM functionality are making it possible to close this missing link in cloud security.