Ed Tice is a sales engineer at Synopsys. While he's a bit of a jack of all trades, his primary areas of expertise involve helping customers understand the mechanics of running static analysis, dynamic analysis, fuzzing, and test prioritization security tools.
How do static analyzers manage code dependencies? There are many ways, but the best static analyzers take a hybrid approach to dependency analysis.
Posted in Developer Enablement, Static Analysis (SAST) | Comments Off on Why dependencies matter for SAST
A very common type of injection defect is cross-site scripting (also known as XSS or HTML injection). Many developers struggle with remediation of XSS because of a misunderstanding of the difference between validation, sanitization, and normalization/canonicalization. Lately, even some security vendors have started suggesting “fixing” injection defects close to the source rather than close to the sink. This seems appealing because a fix close to the source has the potential to fix many defects with only a single code change. However, this suggestion suffers from two painful deficiencies. The first is confusion between validation and sanitization. The second is a misunderstanding of the regression risk associated with broad-impact changes. Once those items are better understood, it’s possible to formulate a viable plan for defect remediation. Validation isn’t enough for XSS Input validation involves ensuring that “input data falls within the expected domain of valid program input.” As an example, if we are expecting a dollar amount as input, only numerals and a decimal point are acceptable input characters. In some cases, validation of input data ensures that there are no special characters in the input and, as a side effect, will indeed prevent an injection attack.
Posted in Security Standards and Compliance | Comments Off on Remediating XSS: Does a single fix work?
“I lost my keys. How long will it take to find them?” This is a laughable question, but it’s analogous to “How long will it take to debug this?” Developers scoff at this question as if it were an unreasonable demand, just as inexperienced project managers are shocked that a simple answer isn’t forthcoming. But this interaction says more about the problem we face than about the people involved. Occasionally, an extended debugging session can be fun, and we enjoy telling those “war stories.” But in reality, debugging is one of the most frustrating and inefficient things that we do. By some estimates, we spend about half of our time on it. Debugging code Although we never know how long it will take to debug a particular problem, we do have some idea of the relative difficulty of resolving various issues. If there is a repeatable null pointer dereference, for example, we can often knock it out in a few minutes. The debugging portion is rarely hard. The code fix isn’t anything to write home about either. In this case, the hard part is deciding what the correct behavior for a particular input should be.
Posted in Static Analysis (SAST) | Comments Off on How is static analysis a productivity tool for engineering teams?