We recently started using Veracode for vulnerability testing. Is there a way to selectively exclude all the third party libraries and focus the scan only on our internal libraries code?
Hi: The answer to your question depends on the language in which the application you are scanning was written.
Java: Veracode respects WAR file structure conventions and treats JARs in the /lib directory as third party code. They are included in Software Composition Analysis results, if you subscribe to that service, but we do not otherwise report vulnerabilities that reside in code in this directory.
C/C++ / .NET: By default only the top level executables will be scanned. The static engine will also follow code paths from the top level executables into third party libraries if they are present, but will not check all possible parts of the third party libraries for flaws. You can go into Advanced Mode and click Show Dependencies if you want to scan all possible paths in the third party dependent libraries for flaws.
PHP/JavaScript/Android/iOS/other languages: It's not possible to exclude third party libraries for these languages.
If you have additional questions, please contact Veracode Support and they can help you further.
Related
You call Library code and Framework code calls your code.
I've been doing a number of xcode projects which required adding external frameworks and libraries.
In the installation of these there was always one common occurance, they would always ask me to go to the Build Phases tab and "link the binary with libraries"
My question is why do both frameworks and libraries get linked this way? I (think) I understand why a library does. For libraries they can't execute themselves so you are pre-compiling them and making their functions available to your classes.
For the framework I am much less clear whats happening here. If the framework calls my code why is this being pre-compiled as a binary? If it's executing my code at runtime should it just be compiled along with the build?
A Framework is a way to bundle a static/dynamic library and it's headers (.h) together. There is also a concept of "versioning" but thats not really used anymore.
If you look into a Framework (its just a directory ), you will see the library (without the .a and "lib" prefix , headers, and a .plist.
I want to be able to add plugins for an application I am developing and as it is a development tool I want other people to be able to write their own plugins.
So my questions are what are the real differences between a framework and a loadable bundle? Which are more suited to being a plugin(accessing of headers, ect) ? And if I use loadable bundles how do I load them at runtime and access their functionality during development?
The plugins should not have to rely on other plugins.
Have you taken a look at NSBundle? It has all the methods you'll need to load the executable code at runtime. You'll want to define some sort of plugin interface to which any plugin will conform.
As for the difference between bundles and frameworks... Both bundles and frameworks are file structures that contain various resources that your app can use. A framework is like a library -- it's something your program links against when you build it. A bundle, on the other hand, is essentially a folder structure containing compiled code that you load at runtime.
Elaborating on the accepted answer, a bundle is more designed to be loaded and then potentially unloaded at a later time during program execution. Frameworks, once loaded are designed to stick around for the life of the process.
Frameworks are also designed to be self contained units of code where a caller calls into the APIs the frameworks exports. Bundles can be used when you want to have code call into the caller's public APIs. Check out ld64's man page. You can get hints for the intended usage of bundles with such options like -bundle_loader
What is the difference between a LIB and DLL? I have read plenty of posts on here about it and there are some good, clear answers however I am writing to ask for clarity on one matter.
Is it better to use a LIB (static link library) when there is only one user e.g. for a administration application client installed locally on the PC? and is it better to use a DLL (Dynamic link library) when there are multiple concurrent users accessing a classic asp application that uses vb6 classes?
A LIB file generally corresponds to a static library, which means that all of the library code that your application uses is compiled directly into your application.
A DLL file represents a dynamic library that your application links to, and then when you want to use code from the library, you call into it dynamically while your application is running.
Of course, you'll frequently see a LIB file for a dynamically-linked library as well. That file contains "stubs" that the linker uses to implicitly link to the DLL.
The obvious benefit of a DLL (dynamic linking) is that one DLL with common functionality can be shared with multiple applications that use that same functionality. Bug fixes can be made in a single place, and only one component has to be updated in order for all of the apps to take advantage of those fixes.
If you only have a single application that uses your code, there's little reason to put it into a DLL. Multiple users on multiple computers are going to have to have their own copy of the DLL anyway, so there will be no code sharing going on in that situation.
All of that said, I have no idea what this question has to do with VB 6. To my knowledge, you can only use it to create ActiveX DLLs (which have a different use case) and it can't create static libraries at all.
I understand for non-iOS targets, using shared libraries can lead to lower memory usage, and also that some companies distribute a library and headers (like Superpin) and a static library allows them to not distribute the source of their product. But outside of those, what are the reasons you'd want to use a static library? I use git for all of my projects, and I usually add external libraries (open source ones) as a submodule. This means they take up disk space locally, but they do not clutter up the repo. Also since iOS doesn't support shared libraries, the benefits of building libraries to promote code reuse seems diminished.
Basically, is there any reason outside of selling closed source libraries that it makes sense to build/use static libraries for iOS?
organization, reuse, and easy integration into other programs.
if you have a library which is used by multiple apps or targets multiple platforms, then you will have to maintain the build for each app. with a library, you let the library maintainer set up the build correctly, then you just link to the result (if it's developed internally, then you'll want to add it as a dependency too).
it's like DRY, but for projects.
libraries become more useful as projects become more complex. you should try to identify what programs (functions, class hierarchies, etc) are reusable outside of your app's context, and put it in a library for easy reuse - like pattern recognition.
once your codebase has hundreds or thousands of files, you will want to minimize what you use, and you will not want to maintain the dependencies manually for each project.
Also since iOS doesn't support shared
libraries, the benefits of building
libraries to promote code reuse seems
diminished.
There's no reason you can't build your own static library to use across multiple projects.
Other than for that purpose and the ones you mentioned I don't think there's much else.
Static libraries allow you to have truly standalone executables. Since all library code is actually, physically present in the executable, you don't have to worry about the exec failing to run because there's a too-old version of some library, or a too-new one, or it's completely missing, etc. And you don't have to worry about your app suddenly breaking because some library got replaced. It cuts down on dependencies and lets your app be more encapsulated.
This post and this post says that with Visual Studio, the run time library can be static/dynamic, and it shouldn't be mixed. Even one can have debugging version/release version for the library. And there are four possibilities (static/dynamic and debug/release).
So, with Visual Studio, the library provider has to provide four different versions of the same library?
ADDED
I tried to link CppUnit test (debug) with release build library, and I got an error. So, I wondered normally library provider might need to provide all the possible combination of libraries.
depends..
under normal cicrcumstances you only provide a realease version. Then you have the option for static/dynamic. In the case of static, you don't have to provide anything since it's static: your lib already contains all functions from the crt it needs. In case of dynamic, it also depends: if you expect your clients to build applications using your lib, they already should have the required lib on their build machine. Else, yes, you can provide them with a crt installer for the dynamic release version (or just ship the corresponding dlls but that's considered rather bad practice)
Also if I remember correctly, you cannot redistribute the debug versions of VS's debug libraries, so in the end this would mean the library provider should only provide one version.
This is really the case with ANY C++ library (we have the same 4 options in our Unix side builds).
Please note that you only have to provide the debug versions if you intend them to be used by other developers, who will need them to debug - otherwise, for end users, you can only provide optimized ones.